We've discussed this before, and the current state of the text is certainly much improved. I'd like to touch on one final point.
The current text reads: Section 4.4.1.2 ( https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) All certificates provided by the server MUST be signed by a signature algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MAY use the deprecated SHA-1 hash algorithm only if the "signature_algorithms" extension provided by the client permits it. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. The first and second paragraph are in conflict, unless the first paragraph's MUST is changed to a SHOULD, or a "MUST if at all possible", ... That is it fine to require the server to send a compatible rather than an incompatible certificate when it has at least one of each, but if the only choice is to fail, the second paragraph says that the server "SHOULD" send what it has, thus the first is not really a MUST as written. The only compromise in the direction of the first paragraph made in the second is that certificates (not self) signed with SHA1 MUST not be sent if the client did not offer to support it, even if that's the only certificate it has, and even if that SHA1 signature will never be used by the client (e.g. with a DANE-EE(3) TLSA record authenticating the server directly). The onus is correctly placed on the client (not on the server) to abort the connection, if the client's security requirements are not met by the server's certificate chain. So I'd like to see the text in the first paragraph changed to a SHOULD or worst-case a qualified "MUST whenever possible". I should also note that the second part of the first paragraph, which says: Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. assumes that the server knows which of its certificates are trust anchors, but this is not something that the server can in general definitely know. All kinds of clients may use all kinds of methods to validate the server chain. So I think there is a final opportunity to polish the text by making it clear that the server SHOULD (whenever possible) send a certificate chain that the client is likely to be able to process, but otherwise proceed to the text in the second paragraph, which says (correctly) that it SHOULD otherwise send what it has, which may indeed prove sufficient to the client despite the apparent signature algorithm mismatch. On a related note, is there in the current draft anything that requires ECDSA certificates to bear ECDSA issuer signatures? Or has that finally been relaxed, allowing the transmission of EE ECDSA certs bearing RSA signatures (ideally the client also signals support for RSA signatures)? This would lift the restriction imposed by: https://tools.ietf.org/search/rfc4492#section-2.2 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- capable public key and be signed with ECDSA. My impression is that the text in the last paragraph of 4.4.1.4: https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with an ECDSA key). seems to have the desired effect. Is that correct? If so, should the change from 4492 be stated more emphatically, making it clear that the older restriction no longer applies? -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
