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

Commentary: Currently the codepoint is TBD 
 does one know what we need to get a code point . 
 if we want one early , we can kick that process off . If not we wait for it to be assigned later in the process . 
 I think we need an early one . It 's not possible yet to implement this to evaluate in various scenarios . We plan to use delegated credentials in our internal infrastructure and then probably would push the implementation back to open source projects like OpenSSL . 
 i think a resolution to is the only thing that is probably holding back the code point . 
 can you please start the code point allocation process now that is resolved ?
Paragraph (version A):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of TBD.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 RFC8446.
Paragraph (version B):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of 34.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 RFC8446.
Draft: draft-ietf-tls-subcerts

Commentary: Hearing no objections on the list , merging this in . can you please spin a new version for WGLC ? 
 Allow the client to send a list of signature schemes that are supported in a delegated credential handshake . 
 Fixed by .
Paragraph (version A):
A client which supports this specification SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client MUST abort with an "unexpected_message" alert.
Paragraph (version B):
If the client receives a delegated credential without indicating
support, then the client 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 client in the "signature_algorithms" extension
and are considered invalid otherwise.  Clients that receive invalid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version B):
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.
Draft: draft-ietf-tls-subcerts

Commentary: LGTM 
 Suggestion from   at IETF 106
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 a delegated credential is compromised,
peers may not issue credentials with a validity period longer than 7
days.  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 delegated credential private key
compromise, 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 A):
Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more
than 7 days.  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 current time is within the validity interval of
the credential and that the credential's time to live 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.
Draft: draft-ietf-tls-subcerts

Commentary: Fix formatting issue in changes . 
 This is trivial and straightforward change so I 'm just going to merge this directly .
Paragraph (version A):
draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  *
Additional security considerations.
Paragraph (version B):
Removed support for PKCS 1.5 RSA signature algorithms.
Paragraph (version B):
Additional security considerations.
Draft: draft-ietf-tls-subcerts

Commentary: I suspect at some point somebody would have asked for an ASN.1 module . I know not everybody uses an  compiler , but some do . I also know   was going through an making for all of the RFCs that include ASN.1 . He also double checked that the ASN.1 module compiles ( if you put a dummy OID in for the TBD it will compile ) . An OID is need from the PKIX arc , but  is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections . 
 " An OID is need from the PKIX arc , but  is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections . " Are you thinking of getting a different  for the DCs , does the cf OID not work ? 
 Sean is talking about the Module Identifier . The CF OID inside the module is fine . 
 The CF OID for the extension works just fine - in fact I should have left the sentence in the PR explaining that . We need an OID for the ASN.1 module ( TBD ) . Technically , I guess we do not need an OID if CF has an ASN.1 module already . But , I suspect there was n't an ASN.1 module . Make sense ? 
 do you know if CF has an ASN.1 module already ? 
 since noone seems to have any objections , merging away . 
 Not having an ASN.1 module for the certificate extension has bit us in the a * * before . I will make one and add it in as an appendix .
Paragraph (version A):
We define a new X.509 extension, DelegationUsage, to be used in the
certificate when the certificate permits the usage of delegated
credentials.
Paragraph (version B):
We define a new X.509 extension, DelegationUsage, to be used in the
certificate when the certificate permits the usage of delegated
credentials.  What follows is the ASN.1 X680 for the DelegationUsage
certificate extension.
Paragraph (version B):
This document also defines an ASN.1 module for the DelegationUsage
certificate extension in module.  IANA is requested to register an
Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX
Module Identifier" arc.  An OID for the DelegationUsage certificate
extension is not needed as it is already assigned to the extension
from Cloudflare's IANA Private Enterprise Number (PEN) arc.
Draft: draft-ietf-tls-subcerts

Commentary: Request an extension point from the IANA experts and add it to the document .
Paragraph (version B):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of TBD.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH) or CertificateRequest (CR)
messages in TLS 1.3 RFC8446.
Draft: draft-ietf-tls-subcerts

Commentary: looks great .
Paragraph (version A):
DelegatedCredential.scheme.
Paragraph (version B):
DelegatedCredential.cred.
Draft: draft-ietf-tls-subcerts

Commentary: The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1 .. 44 .
Paragraph (version A):
Change DelegationUsage extension to be NULL.
Paragraph (version B):
Change DelegationUsage extension to be NULL and define its object
identifier.
Paragraph (version A):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in the TLS 1.3 standard.  This is
expected to be the same as CertificateVerify.algorithm sent by the
server.
Paragraph (version A):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in TLS 1.3.  This is expected
to match the protocol version that is negotiated by the client and
server.
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 CertificateVerify.algorithm sent by the server.
Paragraph (version B):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in RFC8446.  This is expected
to match the protocol version that is negotiated by the client and
server.
Draft: draft-ietf-tls-subcerts

Commentary: Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols . In this PR , I propose explicitly restricting the X.509 KeyUsage of the end - entity certificate . This change is made in the last commit : The two commits that proceed it do n't actually change the semantics of the standard , but clean up the language a bit . If the KeyUsage change is n't adopted , we might consider merging the other two commits . 
 if it 's not too painful , could you move this particular diff above all the others , I think I want to have some more discussion on this one . If its painful , we can just resolve this one first 
 Done , 
 looks like i merged this as a result of merging a dependent PR accidentally . This is fine , we can just discuss this before I put up the next draft versions
Paragraph (version A):
We define a new X.509 extension, DelegationUsage to be used in the
certificate when the certificate permits the usage of delegated
credentials.
Paragraph (version B):
We define a new X.509 extension, DelegationUsage, to be used in the
certificate when the certificate permits the usage of delegated
credentials.
Paragraph (version A):
The client MUST NOT accept a delegated credential unless the server's
end-entity certificate has the DelegationUsage extension.
Paragraph (version B):
It has the DelegationUsage extension.
Paragraph (version B):
It has the digitalSignature key usage enabled (see the Keyusage
type in RFC5280), but has the keyEncipherment and dataEncipherment
usages are disabled.
Draft: draft-ietf-tls-subcerts

Commentary: These came up when I implemented the extension in Go ( ) and I think would be useful to add to the standard . 
 looks good to me
Paragraph (version A):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.
Paragraph (version A):
If the extension is present, the server MAY send a
DelegatedCredential extension.  If the extension is not present, the
server MUST NOT send a credential.  A credential MUST NOT be provided
unless a Certificate message is also sent.
Paragraph (version A):
When negotiating TLS 1.3, and using Delegated credentials, the server
MUST send the DelegatedCredential as an extension in the
CertificateEntry of its end-entity certificate.  When negotiating TLS
ServerHello.
Paragraph (version A):
The DelegatedCredential contains a signature from the public key in
the end-entity certificate using a signature algorithm advertised by
the client in the "signature_algorithms" extension.  Additionally,
the credential's public key MUST be of a type that enables at least
one of the supported signature algorithms.  A delegated credential
MUST NOT be negotiated by the server if its signature is not
compatible with any of the supported signature algorithms or the
credential's public key is not usable with the supported signature
algorithms of the client, even if the client advertises support for
delegated credentials.
Paragraph (version B):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client SHOULD abort with an "unexpected_message" alert.
Paragraph (version B):
If the extension is present, the server MAY send a delegated
credential extension.  If the extension is not present, the server
MUST NOT send a credential.  A credential MUST NOT be provided unless
a Certificate message is also sent.  The server MUST ignore the
extension unless TLS 1.2 or later is negotiated.
Paragraph (version B):
When negotiating TLS 1.3, and using delegated credentials, the server
MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions with any other
certificate.  When negotiating TLS 1.2, the delegated credential MUST
be sent as an extension in the ServerHello.
Paragraph (version B):
The delegated credential contains a signature from the public key in
the end-entity certificate using a signature algorithm advertised by
the client in the "signature_algorithms" extension.  Additionally,
the credential's public key MUST be of a type that enables at least
one of the supported signature algorithms.  A delegated credential
MUST NOT be negotiated by the server if its signature is not
compatible with any of the supported signature algorithms or the
credential's public key is not usable with the supported signature
algorithms of the client, even if the client advertises support for
delegated credentials.
Draft: draft-ietf-tls-subcerts

Commentary: The major changes are : Change the arrow in the LURK vs DC figure . I made it a double arrow : The credential might be offered by the edge and signed by the origin ; in this case , the credential - provisioning step involves mutual authentication . Change " DelegatedCredentialParams " to " Credential " . Logically , this is an undelegated , or to - be - delegated , credential . The name " DelegatedCredentialParams " sounds like it 's the parameters of the credential , e.g. , valid_time .
Paragraph (version A):
When negotiating TLS 1.3, and using Delegated credentials, the server
MUST send the DelegatedCredential as an extension in the
CertificateEntry of its end entity certificate.  When negotiating TLS
ServerHello.
Paragraph (version B):
When negotiating TLS 1.3, and using Delegated credentials, the server
MUST send the DelegatedCredential as an extension in the
CertificateEntry of its end-entity certificate.  When negotiating TLS
ServerHello.
Paragraph (version A):
Use the public key in the credential to verify a signature
provided in the handshake.  That is the CertificateVerify message
in TLS 1.3 or ServerKeyExchange in 1.2.
Paragraph (version A):
If one or more of these criteria are not met, then the Delegated
credential is invalid.  Clients that receive Delegated credentials
that are invalid MUST terminate the connection with an
"illegal_parameter" alert.
Paragraph (version A):
The Delegated Credential's public key which is an encoded
SubjectPublicKeyInfo RFC5280.
Paragraph (version A):
The Signature algorithm and scheme used to sign the Delegated
credential.
Paragraph (version A):
The DelegatedCredential structure is similar to the CertificateVerify
structure in TLS 1.3.  Since the SignatureScheme defined in TLS 1.3,
TLS 1.2 clients should translate the scheme into an appropriate group
and signature algorithm to perform validation.
Paragraph (version B):
The delegated credential's public key, which is an encoded
SubjectPublicKeyInfo RFC5280.
Paragraph (version B):
The signature algorithm used to sign the delegated credential.
Paragraph (version B):
The DelegatedCredential structure is similar to the CertificateVerify
structure in TLS 1.3.  Since the SignatureScheme is defined in TLS
group and signature algorithm to perform validation.
Paragraph (version B):
A single 0 byte which serves as the separator.
Paragraph (version A):
The DelegatedCredentialParams structure.
Paragraph (version B):
The Credential structure.