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. > 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)? 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
