Draft: draft-ietf-lamps-rfc5750-bis

Commentary: Get the key managment items rolled in
historic contains information about algorithms are were used for
prior versions of S/MIME but are no longer considered to meet modern
security standards.
historic contains information about algorithms are were used for
prior versions of S/MIME but are no longer considered to meet modern
security standards.  Support of these algorithms may be needed to
support historic S/MIME messages but SHOULD NOT be used for new mail.
Comparing of email addresses is fraught with peril.  I-D.ietf-lamps-
eai-addresses defines the procedure for doing comparision of
Internationalized email addresses.  US-ASCII email addresses treat
the domain component (right-hand side of the '@') MUST be compared
using a case-insentive function.  The method of doing the comparision
of the local name component SHOULD be done case-insentitive.  Some
localities may perform other transformations on the local name
component before doing the comparision, however an S/MIME client
cannot know what specific localities do.
Comparing of email addresses is fraught with peril.  I-D.ietf-lamps-
eai-addresses defines the procedure for doing comparison of
Internationalized email addresses.  For US-ASCII email addresses the
domain component (right-hand side of the '@') MUST be compared using
a case-insensitive function.  The local name component (left-hand
side of the '@') SHOULD be compared using a case-insensitive
function.  Some localities may perform other transformations on the
local name component before doing the comparison, however an S/MIME
client cannot know what specific localities do.
Implementations SHOULD use deterministic generation for the parameter
'k' for ECDSA as outlined in RFC6979.  EdDSA is defined to generate
this parameter deterministically.
For ECDSA see RFC5758 and RFC6090.  The first reference provides the
signature algorithm's object identifier and the second provides the
signature algorithm's definition.
For EdDSA see I-D.ietf-curdle-pkix and I-D.irtf-cfrg-eddsa.  The
first reference provides the signature algorithm's object identifier
and the second provides the signature algorithm's definition.
For ECDSA see RFC5758 and RFC6090.  The first reference provides the
signature algorithm's object identifier and the second provides the
signature algorithm's definition.  Other curves than durve P-256 MAY
be used as well.
For EdDSA see I-D.ietf-curdle-pkix and I-D.irtf-cfrg-eddsa.  The
first reference provides the signature algorithm's object identifier
and the second provides the signature algorithm's definition.  Other
curves than curve 25519 MAY be used as well.
The subject alternative name extension is used in S/MIME as the
preferred means to convey the email address(es) that correspond(s) to
the entity for this certificate.  Any email addresses present MUST be
encoded using the rfc822Name CHOICE of the GeneralName type as
described in RFC5280, Section 4.2.1.6.  Since the SubjectAltName type
is a SEQUENCE OF GeneralName, multiple email addresses MAY be
present.
The subject alternative name extension is used in S/MIME as the
preferred means to convey the email address(es) that correspond(s) to
the entity for this certificate.  Any US-ASCII email addresses
present MUST be encoded using the rfc822Name CHOICE of the
GeneralName type as described in RFC5280, Section 4.2.1.6.  Any
internationalized email addresses present MUST be encoded using the
otherName CHOICE of the GeneralName type as described in I-D.ietf-
lamps-eai-addresses, Section 3.  Since the SubjectAltName type is a
SEQUENCE OF GeneralName, multiple email addresses MAY be present.
The 4096-bit RSA key size requirement for certificate and CRL
verification is larger than the 2048-bit RSA key sizes for message
signature generation/verification or message encryption/decryption in
RFC5751 because many root CAs included in certificate stores have
already issued root certificates with the 4096-bit key.  The standard
that defines comparable key sizes for DSA is not yet available.  In
particular, FIPS186-2 without Change Notice 1 allowed DSA key sizes
between 512 and 1024 bits, FIPS186-2 with Change Notice 1 only
allowed DSA key sizes of 1024 bits, and FIPS186-3 allowed DSA key
sizes from 1024 to 3072 bits.  Further, 4096-bit keys are normally
only used by Root certificates and not by subordinate CA
certificates, thereby lengthening the root CA certificate's validity
period.
RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to sign certificates
or CRLs.  Such keys were previously considered secure, so processing
previously received signed and encrypted mail may require processing
certificates or CRLs signed with weak keys.  Implementations that
wish to support previous versions of S/MIME or process old messages
need to consider the security risks that result from accepting
certificates and CRLs with smaller key sizes (e.g., spoofed
certificates) versus the costs of denial of service.  If an
implementation supports verification of certificates or CRLs
generated with RSA and DSA keys of less than 2048 bits, it MUST warn
the user.  Implementers should consider providing a stronger warning
for weak signatures on certificates and CRLs associated with newly
received messages than the one provided for certificates and CRLs
associated with previously stored messages.  Server implementations
(e.g., secure mail list servers) where user warnings are not
appropriate SHOULD reject messages with weak cryptography.
RSA keys of less than 2048 bits are now considered by many experts to
be cryptographically insecure (due to advances in computing power),
and should no longer be used to sign certificates or CRLs.  Such keys
were previously considered secure, so processing previously received
signed and encrypted mail may require processing certificates or CRLs
signed with weak keys.  Implementations that wish to support previous
versions of S/MIME or process old messages need to consider the
security risks that result from accepting certificates and CRLs with
smaller key sizes (e.g., spoofed certificates) versus the costs of
denial of service.  If an implementation supports verification of
certificates or CRLs generated with RSA and DSA keys of less than
2048 bits, it MUST warn the user.  Implementers should consider
providing a stronger warning for weak signatures on certificates and
CRLs associated with newly received messages than the one provided
for certificates and CRLs associated with previously stored messages.
Server implementations (e.g., secure mail list servers) where user
warnings are not appropriate SHOULD reject messages with weak
cryptography.
Section 7 : Moved references from Appendix B to this section.
Updated references.  Added informational references to SMIMEv2,
SMIMEv3, and SMIMEv3.1.
Section 7 : Moved references from HistoricMail to this section.
Updated references.  Added informational references to SMIMEv2,
SMIMEv3, and SMIMEv3.1.
Create Appendix B which deals with considerations for dealing with
historic email messages.
MUST support SHA-256.
RFC5754 provides the details for using these algorithms with S/MIME.
MUST support at least one of the following algorithms: RSASSA-PSS
with SHA-256, ECDSA with curve P-256 and SHA-256 or EdDSA with
curve 25519 using PureEdDSA mode.
MUST support at least one of the following algorithms: ECDSA with
curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
mode.
SHOULD support RSASSA-PSS with SHA-256.
Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons.  NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a
section of the community which believes that there might be a
backdoor to these curves.  The EdDSA curves were created in response
to this feeling.  However, there are still significant sections of
the industry which need to have NIST approved algorithms.  For this
reason, both sets of curves are represented in the recieving agent
list, but only a requirement for one is in the sending agent list.
Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons.  NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a
section of the community which believes that there might be a
backdoor to these curves.  The EdDSA curves were created in response
to this feeling.  However, there are still significant sections of
the industry which need to have NIST approved algorithms.  For this
reason, both sets of curves are represented in the recieving agent
list, but there is only a requirement for curve in the sending agent
list.
MUST support RSA Encryption, as specified in RFC3370.
SHOULD- support DH ephemeral-static mode, as specified in RFC3370
and SP800-57.
When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier RFC5652.  The
underlying encryption functions for the key wrap and content
encryption algorithm (RFC3370 and RFC3565) and the key sizes for the
two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm).  As AES-128 CBC is the
mandatory-to-implement content encryption algorithm, the AES-128 key
wrap algorithm MUST also be supported when DH ephemeral-static is
used.
Note that S/MIME v3.1 clients might only implement key encryption and
decryption using the rsaEncryption algorithm.  Note that S/MIME v3
clients might only implement key encryption and decryption using the
Diffie-Hellman algorithm.  Also note that S/MIME v2 clients are only
capable of decrypting content-encryption keys using the rsaEncryption
algorithm.
MUST support ECDH ephemeral-static mode for P-256, as specified in
RFC5753.
MUST support ECDH ephemeral-static mode for X25519 using HKDF-256
for the KDF, as specified in I-D.ietf-curdle-cms-ecdh-new-curves.
MUST- support RSA Encryption, as specified in RFC3370.
When ECDH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier RFC5652.  The
underlying encryption functions for the key wrap and content
encryption algorithm (RFC3370 and RFC3565) and the key sizes for the
two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm).  As both 128 and 256 bit
AES modes are mandatory-to-implment as content encryption algorithms
(ContentEncryptionAlgorithmIdentifier), both the AES-128 and AES-256
key wrap algorithms MUST be supported when ECDH ephemeral-static is
used.
HistoricMail provides information on algorithms support in older
versions of S/MIME.
The SMIMECapabilities attribute includes signature algorithms (such
as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
CBC"), authenticated symmetric algorithms (such as "AES-GCM") and key
encipherment algorithms (such as "rsaEncryption").  There are also
several identifiers that indicate support for other optional features
such as binary encoding and compression.  The SMIMECapabilities were
designed to be flexible and extensible so that, in the future, a
means of identifying other capabilities and preferences such as
certificates can be added in a way that will not cause current
clients to break.
The SMIMECapabilities attribute includes signature algorithms (such
as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and
key encipherment algorithms (such as "rsaEncryption").  There are
also several identifiers that indicate support for other optional
features such as binary encoding and compression.  The
SMIMECapabilities were designed to be flexible and extensible so
that, in the future, a means of identifying other capabilities and
preferences such as certificates can be added in a way that will not
cause current clients to break.
If both signing and encryption can be applied to the content, then
two values for smime-type SHOULD be assigned "signed-*" and
"enveloped-*".  If one operation can be assigned, then this can be
omitted.  Thus, since "certs-only" can only be signed, "signed-"
is omitted.
If both signing and encryption can be applied to the content, then
three values for smime-type SHOULD be assigned "signed-*",
"authEnv-*", and "enveloped-*".  If one operation can be assigned,
then this can be omitted.  Thus, since "certs-only" can only be
signed, "signed-" is omitted.
It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or
"enveloped" without having to tunnel into the CMS payload.
It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed",
"authEnveloped" or "enveloped" without having to tunnel into the CMS
payload.
S/MIME v2 SMIMEv2 specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates.  However, S/MIME v3.2 does not
require a particular certificate request mechanism.
S/MIME v2 SMIMEv2 specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates.  However, S/MIME v4.0 does not
require a particular certificate request mechanism.
An S/MIME user agent MUST NOT generate asymmetric keys less than 1024
bits for use with the RSA signature algorithm.
For 512-bit RSA with SHA-1 see RFC3370 and FIPS186-2 without Change
Notice 1, for 512-bit RSA with SHA-256 see RFC5754 and FIPS186-2
without Change Notice 1, and for 1024-bit through 2048-bit RSA with
SHA-256 see RFC5754 and FIPS186-2 with Change Notice 1.  The first
reference provides the signature algorithm's object identifier, and
the second provides the signature algorithm's definition.
For 512-bit DSA with SHA-1 see RFC3370 and FIPS186-2 without Change
Notice 1, for 512-bit DSA with SHA-256 see RFC5754 and FIPS186-2
without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3370 and
FIPS186-2 with Change Notice 1, for 1024-bit and above DSA with
SHA-256 see RFC5754 and FIPS186-3.  The first reference provides the
signature algorithm's object identifier and the second provides the
signature algorithm's definition.
For RSASSA-PSS with SHA-256, see RFC4056.  For 1024-bit DH, see
RFC3370.  For 1024-bit and larger DH, see SP800-56A; regardless, use
the KDF, which is from X9.42, specified in RFC3370.  For RSAES- OAEP,
see RFC3560.
An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with the RSA signature algorithm.
For 2048-bit through 4096-bit RSA with SHA-256 see RFC5754 and
FIPS186-4.  The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's
definition.
For RSASSA-PSS with SHA-256, see RFC4056.  For RSAES-OAEP, see
RFC3560.