-
Notifications
You must be signed in to change notification settings - Fork 158
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
Removing certificate_types and adding certificate_extensions #290
Changes from all commits
b310d99
5fefbaa
f9a2fec
f3900c3
145a027
c2af640
10b6fb3
4f83ee6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2878,37 +2878,26 @@ immediately follow the server's Certificate message. | |
Structure of this message: | ||
|
||
%%% Authentication Messages | ||
enum { | ||
rsa_sign(1), | ||
dss_sign_RESERVED(2), | ||
rsa_fixed_dh_RESERVED(3), | ||
dss_fixed_dh_RESERVED(4), | ||
rsa_ephemeral_dh_RESERVED(5), | ||
dss_ephemeral_dh_RESERVED(6), | ||
fortezza_dms_RESERVED(20), | ||
ecdsa_sign(64), | ||
(255) | ||
} ClientCertificateType; | ||
|
||
opaque DistinguishedName<1..2^16-1>; | ||
|
||
struct { | ||
ClientCertificateType certificate_types<1..2^8-1>; | ||
opaque certificate_extension_oid<1..2^8-1>; | ||
opaque certificate_extension_values<0..2^16-1>; | ||
} CertificateExtension; | ||
|
||
struct { | ||
SignatureAndHashAlgorithm | ||
supported_signature_algorithms<2..2^16-2>; | ||
DistinguishedName certificate_authorities<0..2^16-1>; | ||
CertificateExtension certificate_extensions<0..2^16-1>; | ||
} CertificateRequest; | ||
|
||
certificate_types | ||
: A list of the types of certificate types that the client may | ||
offer. | ||
|
||
rsa_sign a certificate containing an RSA key | ||
rsa_fixed_dh a certificate containing a static DH key. | ||
|
||
supported_signature_algorithms | ||
: A list of the hash/signature algorithm pairs that the server is | ||
able to verify, listed in descending order of preference. | ||
able to verify, listed in descending order of preference. Any | ||
certificates provided by the client MUST be signed using a | ||
hash/signature algorithm pair found in | ||
supported_signature_algorithms. | ||
|
||
certificate_authorities | ||
: A list of the distinguished names {{X501}} of acceptable | ||
|
@@ -2917,28 +2906,49 @@ certificate_authorities | |
root CA or for a subordinate CA; thus, this message can be used to | ||
describe known roots as well as a desired authorization space. If | ||
the certificate_authorities list is empty, then the client MAY | ||
send any certificate of the appropriate ClientCertificateType, | ||
unless there is some external arrangement to the contrary. | ||
send any certificate that meets the rest of the selection criteria | ||
in the CertificateRequest, unless there is some external arrangement | ||
to the contrary. | ||
|
||
certificate_extensions | ||
: A list of certificate extension OIDs {{RFC5280}} with their allowed | ||
values, represented in DER-encoded format. Some certificate | ||
extension OIDs allow multiple values (e.g. Extended Key Usage). | ||
If the server has included a non-empty certificate_extensions list, | ||
the client certificate MUST contain all of the specified extension | ||
OIDs that the client recognizes. For each extension OID recognized | ||
by the client, all of the specified values MUST be present in the | ||
client certificate (but the certificate MAY have other values as | ||
well). However, the client MUST ignore and skip any unrecognized | ||
certificate extension OIDs. If the client has ignored some of the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps "ignore the contents of"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, if this is clearer. The idea is that the client MUST ignore OIDs in the CertificateRequest that the client does not recognize, MUST not try to match them, and MUST skip to the next OID. From: ekr [mailto:notifications@github.com] In draft-ietf-tls-tls13.mdhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%23discussion_r42053523&data=01%7c01%7candrei.popov%40microsoft.com%7cfbb2d7ae9f43438387ed08d2d4dbba46%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ngmkMfse4HUdeaCjmgIYKb0LEz%2f5Ld0VHYEgC%2fIdi6M%3d:
Perhaps "ignore the contents of"? — There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, that's what I got from it. I don't think it's a big deal either way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, that's how I feel too. Certainly not going to object if folks find "ignore the contents of" clearer. |
||
required certificate extension OIDs, and supplied a certificate | ||
that does not satisfy the request, the server MAY at its discretion | ||
either continue the session without client authentication, or | ||
terminate the session with a fatal unsupported_certificate alert. | ||
|
||
PKIX RFCs define a variety of certificate extension OIDs and their | ||
corresponding value types. Depending on the type, matching | ||
certificate extension values are not necessarily bitwise-equal. It | ||
is expected that TLS implementations will rely on their PKI | ||
libraries to perform certificate selection using certificate | ||
extension OIDs. | ||
|
||
This document defines matching rules for two standard certificate | ||
extensions defined in {{RFC5280}}: | ||
|
||
- The Key Usage extension in a certificate matches the request when | ||
all key usage bits asserted in the request are also asserted in the | ||
Key Usage certificate extension. | ||
|
||
- The Extended Key Usage extension in a certificate matches the | ||
request when all key purpose OIDs present in the request are also | ||
found in the Extended Key Usage certificate extension. The special | ||
anyExtendedKeyUsage OID MUST NOT be used in the request. | ||
|
||
Separate specifications may define matching rules for other certificate | ||
extensions. | ||
{:br } | ||
|
||
The interaction of the certificate_types and | ||
supported_signature_algorithms fields is somewhat complicated. | ||
certificate_types has been present in TLS since SSL 3.0, but was | ||
somewhat underspecified. Much of its functionality is superseded by | ||
supported_signature_algorithms. The following rules apply: | ||
|
||
- Any certificates provided by the client MUST be signed using a | ||
hash/signature algorithm pair found in | ||
supported_signature_algorithms. | ||
|
||
- The end-entity certificate provided by the client MUST contain a | ||
key that is compatible with certificate_types. If the key is a | ||
signature key, it MUST be usable with some hash/signature | ||
algorithm pair in supported_signature_algorithms. | ||
|
||
New ClientCertificateType values are assigned by IANA as described in | ||
{{iana-considerations}}. | ||
|
||
Note: It is a fatal "handshake_failure" alert for an anonymous server to request | ||
client authentication. | ||
|
||
|
@@ -3152,31 +3162,6 @@ In particular: | |
- The certificate type MUST be X.509v3 {{RFC5280}}, unless explicitly negotiated | ||
otherwise (e.g., {{RFC5081}}). | ||
|
||
- The end-entity certificate's public key (and associated | ||
restrictions) has to be compatible with the certificate types | ||
listed in CertificateRequest: | ||
|
||
Client Cert. Type Certificate Key Type | ||
|
||
rsa_sign RSA public key; the certificate MUST allow the | ||
key to be used for signing with the signature | ||
scheme and hash algorithm that will be | ||
employed in the CertificateVerify message. | ||
|
||
ecdsa_sign ECDSA-capable public key; the certificate MUST | ||
allow the key to be used for signing with the | ||
hash algorithm that will be employed in the | ||
CertificateVerify message; the public key | ||
MUST use a curve and point format supported by | ||
the server. | ||
|
||
rsa_fixed_dh Diffie-Hellman public key; MUST use the same | ||
parameters as server's key. | ||
|
||
rsa_fixed_ecdh ECDH-capable public key; MUST use the | ||
ecdsa_fixed_ecdh same curve as the server's key, and MUST use a | ||
point format supported by the server. | ||
|
||
- If the certificate_authorities list in the certificate request | ||
message was non-empty, one of the certificates in the certificate | ||
chain SHOULD be issued by one of the listed CAs. | ||
|
@@ -3186,6 +3171,10 @@ In particular: | |
that this relaxes the constraints on certificate-signing | ||
algorithms found in prior versions of TLS. | ||
|
||
- If the certificate_extensions list in the certificate request message | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You need to remove the certificate types definitions above. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
was non-empty, the end-entity certificate MUST match the extension OIDs | ||
recognized by the client, as described in {{certificate-request}}. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This text seems duplicative of the text describing the extensions. I would suggest just poingint to that section. |
||
Note that, as with the server certificate, there are certificates that use | ||
algorithms/algorithm combinations that cannot be currently used with TLS. | ||
|
||
|
@@ -3554,13 +3543,6 @@ This document uses several registries that were originally created in | |
{{RFC4346}}. IANA has updated these to reference this document. The registries | ||
and their allocation policies (unchanged from {{RFC4346}}) are listed below. | ||
|
||
- TLS ClientCertificateType Identifiers Registry: Future values in | ||
the range 0-63 (decimal) inclusive are assigned via Standards | ||
Action {{RFC2434}}. Values in the range 64-223 (decimal) inclusive | ||
are assigned via Specification Required {{RFC2434}}. Values from | ||
224-255 (decimal) inclusive are reserved for Private Use | ||
{{RFC2434}}. | ||
|
||
- TLS Cipher Suite Registry: Future values with the first byte in | ||
the range 0-191 (decimal) inclusive are assigned via Standards | ||
Action {{RFC2434}}. Values with the first byte in the range 192-254 | ||
|
@@ -3776,13 +3758,11 @@ well, thus allowing ECDSA signatures to be used with digest algorithms other | |
than SHA-1, provided such use is compatible with the certificate and any | ||
restrictions imposed by future revisions of {{RFC5280}}. | ||
|
||
As described in {{server-certificate}} and {{client-certificate}}, the | ||
restrictions on the signature algorithms used to sign certificates are no | ||
longer tied to the cipher suite (when used by the server) or the | ||
ClientCertificateType (when used by the client). Thus, the restrictions on the | ||
algorithm used to sign certificates specified in Sections 2 and 3 of RFC 4492 | ||
are also relaxed. As in this document, the restrictions on the keys in the | ||
end-entity certificate remain. | ||
As described in {{server-certificate}}, the restrictions on the signature | ||
algorithms used to sign certificates are no longer tied to the cipher suite. | ||
Thus, the restrictions on the algorithm used to sign certificates specified in | ||
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, the | ||
restrictions on the keys in the end-entity certificate remain. | ||
|
||
|
||
# Implementation Notes | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have relaxed this restriction for the server and made it a strong SHOULD. Should we do the same here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think algorithm negotiation should be definitive, both for the server and the client. What was the reason for relaxing this requirement for the server?
From: ekr [mailto:notifications@github.com]
Sent: Wednesday, October 14, 2015 2:08 PM
To: tlswg/tls13-spec tls13-spec@noreply.github.com
Cc: Andrei Popov Andrei.Popov@microsoft.com
Subject: Re: [tls13-spec] Removing certificate_types and adding certificate_extensions (#290)
In draft-ietf-tls-tls13.mdhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%23discussion_r42053320&data=01%7c01%7candrei.popov%40microsoft.com%7c6cdffca510b641aa0fbb08d2d4db7ba4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fMWN1xfAm7OxSYibpoJTQcTF0L77fS%2fLRRpm0f%2b37n0%3d:
We have relaxed this restriction for the server and made it a strong SHOULD. Should we do the same here?
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%2ffiles%23r42053320&data=01%7c01%7candrei.popov%40microsoft.com%7c6cdffca510b641aa0fbb08d2d4db7ba4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1HGBdz8tYk6A0R52veLDZKtrs7tmGHCC%2bvtrQNNMWTg%3d.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reasoning was that you have some limited number of certificates and that it's better to provide something than fail the handshake.
I don't care much either way, but I wanted to raise it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Wednesday, October 14, 2015 05:13:52 pm Andrei-Popov wrote:
On Wednesday, October 14, 2015 05:16:36 pm ekr wrote:
The goal was to not fail so the client could make the final decision to abort or not, rather than the server, as the server doesn't always have enough information to make that decision properly.
Doing this in the opposite direction as well could make sense, but giving the client the option to abort rather then send its certificates might be useful in other cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was not a good change for the server. The client explicitly indicated lack of support for the algorithms in the server’s certificate(s), and sending unsupported certificate(s) is an attack on the client. Hopefully, the client will prevent this attack, but the protocol should not put a compliant server in the position of an attacker☺.
For client auth, the argument of “let’s not break the handshake” makes even less sense: a client including an empty certificate does not necessarily fail the handshake. The client simply says “I can’t satisfy this CertificateRequest”.
From: Dave Garrett [mailto:notifications@github.com]
Sent: Wednesday, October 14, 2015 2:30 PM
To: tlswg/tls13-spec tls13-spec@noreply.github.com
Cc: Andrei Popov Andrei.Popov@microsoft.com
Subject: Re: [tls13-spec] Removing certificate_types and adding certificate_extensions (#290)
In draft-ietf-tls-tls13.mdhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%23discussion_r42056072&data=01%7c01%7candrei.popov%40microsoft.com%7c90a90bfaead544bc1a5508d2d4dea5ba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bMJNchGUterSW3etN45PpBWn54LBwAYYZ8%2fuS0GmTJY%3d:
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%2ffiles%23r42056072&data=01%7c01%7candrei.popov%40microsoft.com%7c90a90bfaead544bc1a5508d2d4dea5ba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oK%2bBna9j3zDuTHR736SK0JDZw%2bF3%2fDhxrZ%2bcevbfmlo%3d.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can live with Andrei's proposed text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Wednesday, October 14, 2015 05:51:07 pm Andrei-Popov wrote:
It's not an attack if it knows it's a possibility because it's part of the spec. One of the prime reasons to make the change was to handle things like DANE & opportunistic encryption better, as there's no way for the client to sufficiently inform the server of what it supports (if it cares at all). See the mailing list discussions on this topic, as we're getting off-topic now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off-topic? Somewhat true.
Not an attack? I respectfully disagree; will keep thwarting:).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current version of TLS includes MUST language here, so I suggest that (pending people raising other concerns in the next few days) we land this PR and then we can have a separate issue about whether to relax this requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a plan!