On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > 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. > It's "MUST if... ". That's different from SHOULD unless because it means that the unless clause is that only reason for violating it, and then if that condition obtains it SHOULD do X but could presumably do other things. 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 don't see any difference between "MUST whenever possible" and the current language. On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? No. Nor has that been true since TLS 1.2. See: https://tools.ietf.org/search/rfc5246#section-7.4.2 If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies 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 a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. > 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? > Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't see that this text is relevant. -Ekr > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
