Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renumber new SignatureSchemes. #641

Merged
merged 2 commits into from Sep 21, 2016

Conversation

@davidben
Copy link
Contributor

commented Sep 20, 2016

Avoid both starting with an existing hash AND ending with an existing
SignatureAlgorithm. In principle, this should not be necessary, but TLS
1.2 says:

signature
This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
[PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
"anonymous" value is meaningless in this context but used in
Section 7.4.3. It MUST NOT appear in this extension.

Bouncy Castle appears to have been enforcing this, causing interop
issues. As this was a straight-up MUST NOT, it seems prudent to
renumber. And if we're renumbering anyway, may as well avoid all the old
SignatureAlgorithms and avoid confusing tools like Wireshark.

Avoid both starting with an existing hash AND ending with an existing
SignatureAlgorithm. In principle, this should not be necessary, but TLS
1.2 says:

   signature
      This field indicates the signature algorithm that may be used.
      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
      [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively.  The
      "anonymous" value is meaningless in this context but used in
      Section 7.4.3.  It MUST NOT appear in this extension.

Bouncy Castle appears to have been enforcing this, causing interop
issues. As this was a straight-up MUST NOT, it seems prudent to
renumber. And if we're renumbering anyway, may as well avoid all the old
SignatureAlgorithms and avoid confusing tools like Wireshark.
@@ -4000,8 +4000,13 @@ by IANA
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.

Finally, this document obsoletes a registry originally created in {{RFC5246}}.
IANA [shall/has] updated it to list values 7-223 as "Reserved".
[[TODO: How to denote that values ending in 0x00 through 0x03 are also reserved?]]

This comment has been minimized.

Copy link
@davegarrett

davegarrett Sep 20, 2016

Contributor

We already have a "Values with the first byte..." sentence in its definition. Just add a second:

"Values with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility."

This comment has been minimized.

Copy link
@davidben

davidben Sep 20, 2016

Author Contributor

Done.

IANA [shall/has] updated it to list values 7-223 as "Reserved".
Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS
SignatureAlgorithm Registry, both originally created in {{RFC5246}}. IANA
[shall/has] update the TLS HashAlgorithm Registry to list values 7-223 as

This comment has been minimized.

Copy link
@ekr

ekr Sep 21, 2016

Contributor

NIT: [SHALL update/has updated]

@ekr ekr merged commit 9392d71 into tlswg:master Sep 21, 2016
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
davegarrett added a commit to davegarrett/tls13-spec that referenced this pull request Sep 22, 2016
ekr added a commit that referenced this pull request Sep 22, 2016
update changelog for PR #641
@kazu-yamamoto

This comment has been minimized.

Copy link
Contributor

commented on af59c9c Oct 26, 2016

Thanks to this commit, I can add TLS 1.3's signature algorithms to Haskell TLS library.
Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.