Good catches on the section number and server/client questions. Confirming below.
Here's a PR with the proposed change: https://github.com/tlswg/tls-subcerts/pull/54 On Sat, Feb 15, 2020 at 12:55 AM Ilari Liusvaara <[email protected]> wrote: > On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wrote: > > Ilari, > > > > Thank you for identifying these errors in the document. There was no > > intention to allow the client to constrict the server certificate's > > algorithm with the delegated_credential extension, and no intention to > > restrict the delegated credential's algorithm with the > > signature_algorithms. Let me propose some minor text changes to address > the > > issues. > > > > As a reminder, the CertificateVerify.algorithm is constrained by the > > signature_algorithms > > extension, as stated in RFC 8446: > > > > If the CertificateVerify message is sent by a server, the signature > > algorithm MUST be one offered in the client's "signature_algorithms" > > extension unless no valid certificate chain can be produced without > > unsupported algorithms (see Section 4.2.3 > > <https://tools.ietf.org/html/rfc8446#section-4.2.3>). > > > > > > > > Original text from 4.1.2.: > > > > The 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. > > > > > > proposed text: > > > > The expected_cert_verify_algorithm field MUST be of a > > type advertised by the client in the SignatureSchemeList and is > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > The section number looks incorrect (it is about client authentication) > and the original looks to be copied from the new text. Did you mean > section 4.1.1 (Server authentication) and: > > OLD: > > 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. > > NEW: > > The expected_cert_verify_algorithm field MUST be of a > type advertised by the client in the SignatureSchemeList and is > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > Yes, 4.1.1. I'll put this into a PR. > > > As for the second point, we did not add the capability for the server to > > advertise a different set of signature_algorithms for client > authentication > > other than the one advertised via the "signature_algorithms" extension. > > This was perhaps an oversight. I propose that we add that capability and > > I'd be happy to propose a PR to that effect. > > > > The new text of 4.3.2. would look something like: > > > > A server which supports this specification SHALL send an > > "delegated_credential" extension in the CertificateRequest message > > when requesting client authentication. The body of the > > extension consists of a SignatureSchemeList. If the server receives a > > delegated credential without indicating support in its > > CertificateRequest, then the server MUST abort with an > > "unexpected_message" alert. > > > > ... > > > > The algorithm field MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > of the CertificateRequest message and the > expected_cert_verify_algorithm > > field MUST be of a type advertised by the client in the > SignatureSchemeList > > and considered invalid otherwise. Clients that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > > > There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean > section 4.1.2 (Client authentication)? Yes, 4.1.2 is the right section. > The latter proposed paragraph > seems like it says "client" in two places it should say "server", did you > mean: > > The algorithm field MUST be of a > type advertised by the server in the "signature_algorithms" extension > of the CertificateRequest message and the expected_cert_verify_algorithm > field MUST be of a type advertised by the server in the > SignatureSchemeList > and considered invalid otherwise. Servers that receive invalid > delegated credentials MUST terminate the connection with an > "illegal_parameter" alert. > Yes, that's correct. > > > > -Ilari >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
