jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-subcerts

Commentary: Addresses GENART " default " comment . 
 Need to address and directorate reviews . 
 Correction  editorial are addressed via and . 
 and . 
 Looks good
Paragraph (version A):
Time, in seconds relative to the delegation certificate's
notBefore value, after which the delegated credential is no longer
valid.  Endpoints will reject delegated credentials that expire
more than 7 days from the current time (as described in client-
and-server-behavior).
Paragraph (version B):
Time, in seconds relative to the delegation certificate's
notBefore value, after which the delegated credential is no longer
valid.  Endpoints will reject delegated credentials that expire
more than 7 days from the current time (as described in client-
and-server-behavior) based on the default (see solution-overview.
Paragraph (version A):
Delegated credentials can be valid for 7 days and it is much easier
for a service to create delegated credentials than a certificate
signed by a CA.  A service could determine the client time and clock
skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it.  Client
time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the
number of probes that a server can perform.
Paragraph (version B):
Delegated credentials can be valid for 7 days (by default) and it is
much easier for a service to create delegated credentials than a
certificate signed by a CA.  A service could determine the client
time and clock skew by creating several delegated credentials with
different expiry timestamps and observing whether the client would
accept it.  Client time could be unique and thus privacy sensitive
clients, such as browsers in incognito mode, who do not trust the
service might not want to advertise support for delegated credentials
or limit the number of probes that a server can perform.
Paragraph (version A):
7 days.
Paragraph (version B):
7 days (if the default valid_time is used).
Draft: draft-ietf-tls-subcerts

Commentary: Need to address and directorate reviews . 
 Correction  editorial are addressed via and . 
 and . 
 Also noted in ARTART review .
Paragraph (version A):
The organizational separation between the operator of a (D)TLS
endpoint and the certification authority can create limitations.  For
example, the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the
certification authority.  This document describes a mechanism to to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in (D)TLS without breaking
compatibility with peers that do not support this specification.
Paragraph (version B):
The organizational separation between the operator of a (D)TLS
endpoint and the certification authority can create limitations.  For
example, the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the
certification authority.  This document describes a mechanism to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in (D)TLS without breaking
compatibility with peers that do not support this specification.
Draft: draft-ietf-tls-subcerts

Commentary: Need to address and directorate reviews . 
 Correction  editorial are addressed via and . 
 and . 
 Also noted in ARTART review .
Paragraph (version A):
The initiator uses information from the peer's certificate to
verify the delegated credential and that the peer is asserting an
expected identity, determining an authentication result for the
peer..
Paragraph (version B):
The initiator uses information from the peer's certificate to
verify the delegated credential and that the peer is asserting an
expected identity, determining an authentication result for the
peer.
Draft: draft-ietf-tls-subcerts

Commentary: Added text to address issue 
 There is a potential issue for credential renewal . On the credential owners side there is a risk that if the owner entirely depends upon the delegated credential lifetime to renew it could miss the fact that the underlying certificate has already expired will cause clients to fail validation . This can be addressed by adding the following to section 3 : " Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or extend beyond the validity period of the X.509 certificate " Or there could be an addition to the operational section that talks about renewal . " 5.2 Credential Renewal Credentials must be renewed before they expire and before the issuing X.509 certificate expires . " 
 addressed by pull request
Paragraph (version A):
Delegated credentials allow a peer to terminate TLS connections on
behalf of the certificate owner.  If a credential is stolen, there is
no mechanism for revoking it without revoking the certificate itself.
To limit exposure in case of the compromise of a delegated
credential's private key, delegated credentials have a maximum
validity period.  In the absence of an application profile standard
specifying otherwise, the maximum validity period is set to 7 days.
Peers MUST NOT issue credentials with a validity period longer than
the maximum validity period.  This mechanism is described in detail
in client-and-server-behavior.
Paragraph (version B):
Delegated credentials allow a peer to terminate TLS connections on
behalf of the certificate owner.  If a credential is stolen, there is
no mechanism for revoking it without revoking the certificate itself.
To limit exposure in case of the compromise of a delegated
credential's private key, delegated credentials have a maximum
validity period.  In the absence of an application profile standard
specifying otherwise, the maximum validity period is set to 7 days.
Peers MUST NOT issue credentials with a validity period longer than
the maximum validity period or that extends beyond the validity
period of the delegation certificate.  This mechanism is described in
detail in client-and-server-behavior.
Draft: draft-ietf-tls-subcerts

Commentary: Addresses . 
 The text in s7.6 , needs an intro to explain why it talks about TLS 1.2 when this extension is only applicable to TLS 1.3 . From . 
 I do n't think this is really necessary , but
Paragraph (version B):
Delegated credentials are only used in TLS 1.3 connections.  However,
the certificate that signs a delegated credential may be used in
other contexts such as TLS 1.2.  Using a certificate in multiple
contexts opens up a potential cross-protocol attack against delegated
credentials in TLS 1.3.
Draft: draft-ietf-tls-subcerts

Commentary: Addresses a comment from from .
Paragraph (version A):
The signature algorithm of the Credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as the sender's CertificateVerify.algorithm.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID.  As a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Paragraph (version B):
The signature algorithm of the Credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as the sender's CertificateVerify.algorithm (as described
in validating-a-delegated-credential).  Only signature algorithms
allowed for use in CertificateVerify messages are allowed.  When
using RSA, the public key MUST NOT use the rsaEncryption OID.  As
a result, the following algorithms are not allowed for use with
delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
rsa_pss_rsae_sha512.
Draft: draft-ietf-tls-subcerts

Commentary: Addresses . 
 .Add some additional text to highlight that sig on server cert and DC can be different . from .
Paragraph (version A):
Each delegated credential is bound to a specific signature
algorithm for use use in the TLS handshake (RFC8446 section
unintended signature algorithms.
Paragraph (version B):
Each delegated credential is bound to a specific signature
algorithm for use in the TLS handshake (RFC8446 section 4.2.3).
This prevents them from being used with other, perhaps unintended
signature algorithms.  The signature algorithm bound to the
delegated credential can be chosen independantly of the set of
signature algorithms supported by the end-entity certificate.
Draft: draft-ietf-tls-subcerts

Commentary: Addresses . 
 Tweak some of the text in  to be explain downgrade protections . from .
Paragraph (version A):
If the extension is present, the server MAY send a delegated
credential; if the extension is not present, the server MUST NOT send
a delegated credential.  The server MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.
Paragraph (version B):
If the extension is present, the server MAY send a delegated
credential; if the extension is not present, the server MUST NOT send
a delegated credential.  The server MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.  An example of when a
server could choose not to send a delegated credential is when the
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
Draft: draft-ietf-tls-subcerts

Commentary: Addresses . 
   to : case description from .
Paragraph (version B):
Server operators often deploy TLS termination services in locations
such as remote data centers or Content Delivery Networks (CDNs) where
it may be difficult to detect key compromises.  Short-lived
certificates may be used to limit the exposure of keys in these
cases.
Paragraph (version A):
These dependencies cause problems in practice.  Server operators
often deploy TLS termination services in locations such as remote
data centers or Content Delivery Networks (CDNs) where it may be
difficult to detect key compromises.  Short-lived certificates may be
used to limit the exposure of keys in these cases.
Draft: draft-ietf-tls-subcerts

Commentary: Update the condition for validating a DC to the following : now ( ) < = notBefore + valid_time < = now ( ) + 7d 
 LGTM % nit
Paragraph (version A):
Time in seconds relative to the beginning of the delegation
certificate's notBefore value after which the delegated credential
is no longer valid.  Endpoints will reject delegate credentials
with valid_times exceeding 7 days (as described in client-and-
server-behavior).
Paragraph (version B):
Time in seconds relative to the beginning of the delegation
certificate's notBefore value after which the delegated credential
is no longer valid.  Endpoints will reject delegated credentials
that expire more than 7 days from the current time (as described
in client-and-server-behavior).
Paragraph (version A):
Validate that DelegatedCredential.cred.valid_time is no more than
7 days.
Paragraph (version A):
Verify that the current time is within the validity interval of
the credential.  This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time.
Paragraph (version A):
Verify that the delegated credential's remaining validity time is
no more than the maximum validity period.  This is done by
asserting that the current time is no more than the delegation
certificate's notBefore value plus
DelegatedCredential.cred.valid_time plus the maximum validity
period.
Paragraph (version B):
Verify that the current time is within the validity interval of
the credential.  This is done by asserting that the current time
does not exceed the expiry time.
Paragraph (version B):
Verify that the delegated credential's remaining validity period
is no more than the maximum validity period.  This is done by
asserting that the expiry time does not exceed the current time
plus the maximum validity period (7 days).
Draft: draft-ietf-tls-subcerts

Commentary: ./cc 
 That is perfect ! Thank you !
Paragraph (version A):
The signature algorithm of the Credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as CertificateVerify.algorithm sent by the server.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID.  As a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Paragraph (version B):
The signature algorithm of the Credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as the sender's CertificateVerify.algorithm.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID.  As a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Draft: draft-ietf-tls-subcerts

Commentary: From  : I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage . From  : One of the hard requirements for our deployment was that the same certificate be useable with DCs and without . A different EKU would be more problematic then an extension for this purpose , and while it might be more or less irritating for implementors depending on how their stack works ( sorry Rich - https://boringssl- might serve as inspiration , but the client side got dropped for similar issues ) . We know the extension does n't bust things , I do n't know an EKU would , and the root program issues make me hesitate . 
 Addressed in
Paragraph (version B):
A new extension was chosen instead of adding a new Extended Key Usage
(EKU) to be compatible with deployed TLS and PKI software stacks
without requiring CAs to issue new intermediate certificates.
Draft: draft-ietf-tls-subcerts

Commentary: In section 3 , the document says : The secret key used to sign ... Please change " secret " to " private " . Later in the sentence , [ RFC5280 ] is referenced , and it talks about " private key " in this context . 
 Addressed in
Paragraph (version A):
A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval and a public key (along with its
associated signature algorithm).  The signature on the credential
indicates a delegation from the certificate that is issued to the
peer.  The secret key used to sign a credential corresponds to the
public key of the peer's X.509 end-entity certificate RFC5280.
Paragraph (version B):
A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval and a public key (along with its
associated signature algorithm).  The signature on the credential
indicates a delegation from the certificate that is issued to the
peer.  The private key used to sign a credential corresponds to the
public key of the peer's X.509 end-entity certificate RFC5280.
Draft: draft-ietf-tls-subcerts

Commentary: From  : I wonder how much more needs to be said about expiration dates and allowance for clock skew . We have n't had any trouble with the mechanism proposed here ( to my knowledge ) , but we 've had plenty of trouble with ESNI deployment . Maybe the design here is sufficiently superior that it is less susceptible to problems , but it 's not clear that this is indeed the case . Our implementation follows the spec when it comes to the validity period , but we ca n't really prevent skew from causing credentials to be rejected . What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter . This effectively means that servers need to set valid_time values that are n't too far in the future based on their tolerance for client clock skew . For a 7 - day credential , you might get 5 good days of use . A little bit of a nod in this direction might go a long way to avoiding deployment problems . 
 Fixed in
Paragraph (version B):
Fix section bullets in 4.1.3.
Paragraph (version A):
Verify that the current time is within the validity interval of
the credential.  This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time.  2 Verify that the
credential's remaining validity time is no more than the maximum
validity period.  This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time plus the maximum validity
period.
Paragraph (version B):
Verify that the current time is within the validity interval of
the credential.  This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time.
Paragraph (version B):
Verify that the credential's remaining validity time is no more
than the maximum validity period.  This is done by asserting that
the current time is no more than the delegation certificate's
notBefore value plus DelegatedCredential.cred.valid_time plus the
maximum validity period.
Paragraph (version B):
One of the risks of deploying a short-lived credential system based
on absolute time is client clock skew.  If a client's clock is
sufficiently ahead or behind of the server's clock, then clients will
reject credentials that are valid from the server's perspective.
Clock skew also affects the validity of the original certificates.
The lifetime of the delegated credential should be set taking clock
skew into account.  Clock skew may affect a delegated credential at
the beginning and end of its validity periods, which should also be
taken into account.
Draft: draft-ietf-tls-subcerts

Commentary: Closed in 
 good catch
Paragraph (version A):
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the client in the SignatureSchemeList and are
considered invalid otherwise.  Clients that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter"
alert.
Paragraph (version A):
A server which supports this specification SHALL send an empty
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication.  If the server receives a
delegated credential without indicating support in its
CertificateRequest, then the server MUST abort with an
"unexpected_message" alert.
Paragraph (version B):
The expected_cert_verify_algorithm field MUST be of a type advertised
by the client in the SignatureSchemeList and is considered invalid
otherwise.  Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
Paragraph (version B):
A server that supports this specification SHALL send a
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication.  The body of the extension
consists of a SignatureSchemeList.  If the server receives a
delegated credential without indicating support in its
CertificateRequest, then the server MUST abort with an
"unexpected_message" alert.
Paragraph (version A):
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the server in the "signature_algorithms" extension
and are considered invalid otherwise.  Servers that receive invalid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version B):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
and the expected_cert_verify_algorithm field MUST be of a type
advertised by the server in the SignatureSchemeList and considered
invalid otherwise.  Servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter"
alert.
Draft: draft-ietf-tls-subcerts

Commentary: Also fixed a few smaller grammatical / punctuation errors . Rationale from the mailing list : I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong , but that is n't really made explicit . I'm not sure what " only " means in " only in degraded performance . " Is it " the worst that can happen is just degraded performance " or " it can result only in degraded performance , as opposed to better performance " ? At first I thought it was the latter , but after reading the subsequent sentence , I realized it was probably the former . The use of " On the other hand " sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance , which obviously would be silly .
Paragraph (version A):
These dependencies cause problems in practice.  Server operators
often want to create short-lived certificates for servers in low-
trust zones such as Content Delivery Network (CDNs) or remote data
centers.  This allows server operators to limit the exposure of keys
in cases that they do not realize a compromise has occurred.  The
risk inherent in cross-organizational transactions makes it
operationally infeasible to rely on an external CA for such short-
lived credentials.  In Online Certificate Status Protocol (OCSP)
stapling (i.e., using the Certificate Status extension type ocsp
RFC8446, if an operator chooses to talk frequently to the CA to
obtain stapled responses, then failure to fetch an OCSP stapled
response results only in degraded performance.  On the other hand,
failure to fetch a potentially large number of short lived
certificates would result in the service not being available, which
creates greater operational risk.
Paragraph (version B):
These dependencies cause problems in practice.  Server operators
often want to create short-lived certificates for servers in low-
trust zones such as Content Delivery Networks (CDNs) or remote data
centers.  This allows server operators to limit the exposure of keys
in cases where they do not realize a compromise has occurred.
However, the risk inherent in cross-organizational transactions makes
it operationally infeasible to rely on an external CA for such short-
lived credentials.  For instance, in the case of Online Certificate
Status Protocol (OCSP) stapling (i.e., using the Certificate Status
extension type ocsp RFC8446), a CA may fail to deliver OCSP stapled
response.  While this will result in degraded performance, the
ramifications of failing to deliver short-lived certificates are even
worse: the service that depends on those certificates would go down
entirely.  Thus, ensuring independence from CAs for short-lived
certificates is critical to the uptime of a service.