Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

[Nick Sullivan <[e-mail]>]

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 <[e-mail]>
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
>