Draft: draft-ietf-lamps-rfc5750-bis

Commentary: Change to version number 4.0 Setup historical pointers Correct trust statement
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.
S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described
in RFC5751, provides a method to send and receive secure MIME
messages.  Before using a public key to provide security services,
the S/MIME agent MUST verify that the public key is valid.  S/MIME
agents MUST use PKIX certificates to validate public keys as
described in the Internet X.509 Public Key Infrastructure (PKIX)
Certificate and CRL Profile RFC5280.  S/MIME agents MUST meet the
certificate processing requirements documented in this document in
addition to those stated in RFC5280.
S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described
in I-D.ietf-lamps-rfc5751-bis, provides a method to send and receive
secure MIME messages.  Before using a public key to provide security
services, the S/MIME agent MUST verify that the public key is valid.
S/MIME agents MUST use PKIX certificates to validate public keys as
described in the Internet X.509 Public Key Infrastructure (PKIX)
Certificate and CRL Profile RFC5280.  S/MIME agents MUST meet the
certificate processing requirements documented in this document in
addition to those stated in RFC5280.
S/MIME version 3.2 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
historic contains information about algorithms are were used for
prior versions of S/MIME but are no longer considered to meet modern
security standards.
Mandated support for ECDSA for P-256 and Ed25519.  Moved
algorithms with SHA-1 and MD5 to historical status.  Moved DSA
support to historical status.  Increased lower bounds on RSA key
sizes.
Add a new appendix for algorithms that are now considered to be
historical.
S/MIME version 3.5 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
SMIMEv2, S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035 SMIMEv3, S/MIME version 3.1 is described in
RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 SMIMEv3.1, and
S/MIME version 3.2 is described in SMIMEv3.2.  RFC 2311 also has
historical information about the development of S/MIME.
S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
SMIMEv2, S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035 SMIMEv3, S/MIME version 3.1 is described in
RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 SMIMEv3.1, and
S/MIME version 3.2 is described in SMIMEv3.2.  RFC 2311 also has
historical information about the development of S/MIME.
S/MIME v3.5 implementations MUST support both issuerAndSerialNumber
and subjectKeyIdentifier.  Messages that use the subjectKeyIdentifier
choice cannot be read by S/MIME v2 clients.
S/MIME v4.0 implementations MUST support both issuerAndSerialNumber
and subjectKeyIdentifier.  Messages that use the subjectKeyIdentifier
choice cannot be read by S/MIME v2 clients.
then the sending agent SHOULD use AES-256 GCM because it is a
stronger algorithm and is required by S/MIME v3.5.  If the sending
agent chooses not to use AES-256 GCM in this step, it SHOULD use
AES-128 CBC.
then the sending agent SHOULD use AES-256 GCM because it is a
stronger algorithm and is required by S/MIME v4.0.  If the sending
agent chooses not to use AES-256 GCM in this step, it SHOULD use
AES-128 CBC.