jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-schaad-curdle-oid-registry

Commentary: Deal with early IANA review
Future updates to this table require both 'Specification Required'
and 'Expert Review' as defineed in RFC5226.
The registry is to be created using the "Specification Required"
policy as defined in RFC8126.
Draft: draft-schaad-curdle-oid-registry

Commentary: Comments from Ilari , , Martin ,
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for use
by that working group.  This document describes the range of
identifiers that were assigned in that donated range, transfers
control of that range to IANA, and establishes IANA allocation
policies for any future assignments within that range.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for the
purpose of registering the Edwards Elliptic Curve key agreement and
signature algorithms.  This donated set of OIDs allowed for shorter
values than would be possible using the existing S/MIME or PKIX arcs.
This document describes the range of identifiers that were assigned
in that donated range, transfers control of that range to IANA, and
establishes IANA allocation policies for any future assignments
within that range.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for use
by that working group.  These object identifiers are primarily used
with Abstract Syntax Notation (ASN.1) ASN.1.  The ASN.1
specifications continue to evolve, but object identifiers can be used
with any and all versions of ASN.1.
This document describes the object identifiers that were assigned in
that donated range, transfers control of the range to IANA, and
establishes IANA allocation policies for any future assignments
within that range.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for use
by that working group.  The use of these object identifiers allowed
for the Edwards Ellitptic Curve key agreement RFC7748 and signature
RFC8032 algorithms to be defined with encodings that are smaller than
similar ones would be if assigned from the existing S/MIME or PKIX
arcs.  These initial registrations from this arc were done while
developing I-D.ietf-curdle-pkix.  After those registrations were
done, there were still some unused values that can be used for other
security groups, there were still some unused values.
Object identifiers are primarily used with Abstract Syntax Notation
(ASN.1) ASN.1.  The ASN.1 specifications continue to evolve, but
object identifiers can be used with any and all versions of ASN.1.
This document describes the object identifiers that were assigned in
that donated range, transfers control of the range to IANA, and
establishes IANA allocation policies for any future assignments.
Future updates to this table require both 'Specification Required'
and 'Expert Review' as defiened in RFC5226.
The value of 100 has been reserved so that a new arc below that point
can be established in the future.  (I.e. starting at 1.3.101.100.1)
If the new child registry is established, a name for this value is to
be assigned at that point.  The experts can, at their discretion,
assign an algorithm OID instead.
Future updates to this table require both 'Specification Required'
and 'Expert Review' as defineed in RFC5226.
Draft: draft-schaad-curdle-oid-registry

Commentary: Changed the name of my company / BU in three places
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Security for use by that
working group.  This document describes the range of identifiers that
were assigned in that donated range, transfers control of that range
to IANA, and establishes IANA allocation policies for any future
assignments within that range.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for use
by that working group.  This document describes the range of
identifiers that were assigned in that donated range, transfers
control of that range to IANA, and establishes IANA allocation
policies for any future assignments within that range.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Security for use by that
working group.  These object identifiers are primarily used with
Abstract Syntax Notation (ASN.1) ASN.1.  The ASN.1 specifications
continue to evolve, but object identifiers can be used with any and
all versions of ASN.1.
When the Curdle Security Working Group was chartered, a range of
object identifiers was donated by Symantec Website Security for use
by that working group.  These object identifiers are primarily used
with Abstract Syntax Notation (ASN.1) ASN.1.  The ASN.1
specifications continue to evolve, but object identifiers can be used
with any and all versions of ASN.1.
Draft: draft-ietf-lamps-rfc5751-bis

Commentary: WGLC comments from
Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it.  This is
one of the reasons for moving from EnvelopedData to AuthEnvelopedData
as the authenticated encryption algorithms provide the authentication
without needing the SignedData layer.
Modification of the ciphertext in EnvelopedData can go undetected if
authentication is not also used, which is the case when sending
EnvelopedData without wrapping it in SignedData or enclosing
SignedData within it.  This is one of the reasons for moving from
EnvelopedData to AuthEnvelopedData as the authenticated encryption
algorithms provide the authentication without needing the SignedData
layer.
Draft: draft-ietf-lamps-rfc5751-bis

Commentary: This adds a security consideration for padding . THis addresses issue 
 With the move from CBC to GCM as a padding mode , there is now no padding for a S / MIME message at all . We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size .
Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it.
Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it.  This is
one of the reasons for moving from EnvelopedData to AuthEnvelopedData
as the authenticated encryption algorithms provide the authentication
without needing the SignedData layer.
Draft: draft-ietf-lamps-rfc5750-bis

Commentary: Move the pointer to docs for historical algorithms to the historic appendix . Correct the fact that this is now a WG document .
For 512-bit RSA with SHA-1 see RFC3279 and FIPS186-2 without Change
Notice 1, for 512-bit RSA with SHA-256 see RFC4055 and FIPS186-2
without Change Notice 1, 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.
For 512-bit DSA with SHA-1 see RFC3279 and FIPS186-2 without Change
Notice 1, for 512-bit DSA with SHA-256 see RFC5758 and FIPS186-2
without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3279 and
FIPS186-2 with Change Notice 1, for 1024-bit through 3072 DSA with
SHA-256 see RFC5758 and FIPS186-3.  In either case, the first
reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition.
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.
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.
Draft: draft-schaad-rfc5750-bis

Commentary: Update text dealing with signature algorithms .
MUST support ECDSA with curve P-256 with SHA-256.
MUST NOT support EdDSA using Pre-hash mode.
generated with RSA and DSA keys of less than 1024 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.
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.
SHOULD- support RSA with SHA-1.
SHOULD- support DSA with SHA-1.
SHOULD- support RSA with SHA-1 or DSA with SHA-1.
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
rsaEncryption and might not implement sha256withRSAEncryption.  Note
that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field.  Receiving clients SHOULD
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
clients MUST use id-dsa-with-sha1 if using that algorithm.  Also note
that S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not
implement id-dsa-with-sha1 or id-dsa at all.
MUST support ECDSA with curve P-256 and SHA-256.
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.
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.
An S/MIME user agent MUST NOT generate asymmetric keys less than 512
bits for use with the RSA or DSA signature algorithms.
An S/MIME user agent MUST NOT generate asymmetric keys less than 1024
bits for use with the RSA signature algorithm.
Draft: draft-ietf-lamps-rfc5751-bis

Commentary: Update the document to match the discussion on the mailing list for Content Encryption Algorithms .
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
spasm-wg/smime>.  Instructions are on that page as well.  Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the SPASM mailing list.
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
lamps-wg/smime>.  Instructions are on that page as well.  Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the LAMPS mailing list.
Add the use of AES-GCM (ContentEncryptionAlgorithmIdentifier).
Update the content encryption algorithms
(ContentEncryptionAlgorithmIdentifier): Add AES-256 GCM , remove
AES-192 CBC, mark tripleDES as historic.
MUST support encryption and decryption with AES-128 CBC RFC3565
and AES-128 GCM RFC5084.
SHOULD+ support encryption and decryption with AES-192 CBC,
AES-256 CBC RFC3565, AES-192 GCM and AES-256 GCM RFC5084.
SHOULD- support encryption and decryption with DES EDE3 CBC,
hereinafter called "tripleDES" RFC3370.
MUST support encryption and decryption with AES-128 GCM and
AES-256 GCM RFC5084.
MUST- support encryption and decryption with AES-128 CBC RFC3565.
SHOULD+ support encryption and decryption with ChaCha20-Poly1305
RFC7905.
then the sending agent SHOULD use AES-128 CBC because it is a
stronger algorithm and is required by S/MIME v3.2.  If the sending
agent chooses not to use AES-128 CBC in this step, it SHOULD use
tripleDES.
All algorithms that use 40-bit keys are considered by many to be weak
encryption.  A sending agent that is controlled by a human SHOULD
allow a human sender to determine the risks of sending data using a
weak encryption algorithm before sending the data, and possibly allow
the human to use a stronger encryption method such as tripleDES or
AES.
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.
All algorithms that use 112-bit keys are considered by many to be
weak encryption.  A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data
using a weak encryption algorithm before sending the data, and
possibly allow the human to use a stronger encryption method such as
AES GCM or AES CBC.
Draft: draft-schaad-rfc5751-bis

Commentary: Add a reference marker for this verison of S / MIME
The corroboration that the source of the data received is as
claimed.  RFC4949.
Draft: draft-schaad-rfc5751-bis

Commentary: Add security consideration on origination and authenticated encryption algorithms
This section describes the format for enveloping a MIME entity
without signing it.  It is important to note that sending
authenticated enveloped but not signed messages does not provide for
authentication or non-repudiation.  It is possible to replace
ciphertext in such a way that the processed message will still be
valid, but the meaning can be altered.
The starting key must be bound to a single entity.  The use of a
group key only would allow for the statement that a message was
sent by one of the entities that held the key but will not
identify a specific entity.
The message must have exactly one sender and one recipient.
Having more than one recipient would allow for the second
recipient to create a message that the first recipient would
believe is from the sender by stripping them as a recipient from
the message.
A direct path needs to exist from the starting key to the key used
as the content encryption key (CEK) which guarantees that no third
party could have seen the resulting CEK.  This means that one
needs to be using an algorithm that is called a "Direct
Encryption" or a "Direct Key Agreement" algorithm in other
contexts.  This means that the starting key is used directly as
the CEK key, or that the starting key is used to create a secret
which then is transformed into the CEK via a KDF step.
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.
Draft: draft-schaad-rfc5751-bis

Commentary: Move from artwork to tables for some data
There are several CMS content types.  Of these, only the Data,
SignedData, EnvelopedData, and CompressedData content types are
currently used for S/MIME.
There are several CMS content types.  Of these, only the Data,
SignedData, EnvelopedData, CompressedData, and AuthEnvelopedData
content types are currently used for S/MIME.