Draft: draft-ietf-lamps-rfc5750-bis

Commentary: What is left : * * Use of AES - GCM as first should algorithm for sending messages when no information known . Suggests that maybe we should make it AES - CBC-256 , AES - CBC-128 rather than AES - GCM-128 , AES - CBC-128
The term RSA in this document almost always refers to the PKCS#1 v1.5
RSA signature algorithm even when not qualified as such.  There are a
couple of places where it refers to the general RSA cryptographic
operation, these can be determined from the context where it is used.
For 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and
FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see
RFC4055 and RFC3447.  In either case, the first reference provides
the signature algorithm's object identifier and the second provides
the signature algorithm's definition.
The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys
are specified in [RFC4055] and the signature algorithm definition is
found in [FIPS186-2] with Change Notice 1.
The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in
[RFC4055] and the signature algorithm definition is found in
[RFC3447].
The term RSA in this document almost always refers to the PKCS#1 v1.5
RSA signature or encryption algorithms even when not qualified as
such.  There are a couple of places where it refers to the general
RSA cryptographic operation, these can be determined from the context
where it is used.
Update the set of digest algorithms (DigestAlgorithmIdentifier:
Add SHA-512, mark SHA-1 as historic.
Update the set of digest algorithms (DigestAlgorithmIdentifier):
Add SHA-512, mark SHA-1 as historic.
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.
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").  The presence
of an algorthm based SMIME Capability attribute in this sequence
implies that the sender can deal with the algorithm as well as
undertanding the ASN.1 structures associated with that algorithm.
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 smime-type parameter for authenticated enveloped-only messages is
"authEnvelopedData".  The file extension for this type of message is
".p7m".
The smime-type parameter for authenticated enveloped-only messages is
"authEnveloped-data".  The file extension for this type of message is
".p7m".
An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with the RSA signature algorithm.
An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with an RSA signature algorithm.
The choice of 2048 bits as the RSA asymmetric key size in this
specification is based on the desire to provide at least 100 bits of
security.  The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on RFC3766.  Of
course, there are environments, such as financial and medical
systems, that may select different key sizes.  For this reason, an
implementation MAY support key sizes beyond those recommended in this
specification.
The choice of 2048 bits as an RSA asymmetric key size in this
specification is based on the desire to provide at least 100 bits of
security.  The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on RFC3766.  Of
course, there are environments, such as financial and medical
systems, that may select different key sizes.  For this reason, an
implementation MAY support key sizes beyond those recommended in this
specification.
S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a pre-existing shared
secret when doing encryption, this means that the first precondition
is not met.  There is a document RFC6278 which defined how to use
static-static key agreement with CMS so that is readably doable.
Currently, all S/MIME key agreement methods derive a KEK and wrap a
CEK.  This violates the third precondition above.  New key key
agreement algorithms that directly created the CEK without creating
an intervening KEK would need to be defined.
S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a shared secret for
encryption, this means that the first precondition is not met.  There
is a document RFC6278 which defined how to use static-static key
agreement with CMS so that is readably doable.  Currently, all S/MIME
key agreement methods derive a KEK and wrap a CEK.  This violates the
third precondition above.  New key agreement algorithms that directly
created the CEK without creating an intervening KEK would need to be
defined.