Re: [TLS] Updated TLS 1.2 I-D

Concerning Certificate Verify message:
>       If the SignatureAlgorithm
>       is DSA, then the sha_hash value must be used. If it is RSA,
>       the same function (denoted Hash) must be used as was used to
>       create the signature for the client's certificate.

This doesn't look reasonable.

Aside from general "bad feeling" about this, i have at least three
examples in which this causes trouble:

1) First situation is a constrained client, which uses
client_certificate_url extension, and doesn't have to know it's own
certificate, only it's own private key. The heuristic that you propose
forces this client to also know the hash algorithm used by CA.

2) The second situation is a simple client implementation which
supports only one hash function. This paragraph forces it to support
also the hash functions, which were used by CA to sign his
certificates.

3) The third situation is this: a client posesses a certificate,
issued by a CA with a good hash function, which is not yet supported
by TLS HashType enum (e.g. SHA384). Certificate Request message, which
now contains a list of supported hash types, cannot contain such a
value, so the client is forced not to use such a certificate.

My proposition is:

1) Change the structure of the CertificateVerify message to reflect
the change to CertificateRequest:

       struct {
            HashType hash_type;
            Signature signature;
       } CertificateVerify;

Change the text to following:

       The Signature type is defined in 7.4.3. Client chooses a hash function
       (denoted Hash) from the list, contained in the
CertificateRequest.certificate_hash to
       create the signature for the client's certificate, and
specifies it's type in the
       CertificateVerify.hash_type field.

       CertificateVerify.signature.hash
           Hash(handshake_messages);

2) I think, the role of the CertificateRequest.certificate_hash list
must be clearly stated in the draft.

I see 3 possible choices:
a) it is provided to the client as a guidance
b) the server MUST verify that the CertificateVerify message uses one
of the hash_types that it proposed
c) the server MUST verify that the CertificateVerify message AND the
client certificate chain uses only the proposed set of hashes

I would strongly prefer the "b" case, because the "a" case can lead to
the sitiuation where the server cannot verify client's signature, and
the "c" case forces us to specify HashTypes for all the hash functions
supported by PKIX (see the 3d situation above).

The only alternative i see to this set of changes is to omit the
certificate_hash list from CertificateRequest completely, and state
that the Hash function is chosen by the cipher suite.

Regards,
Greg Chudov

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls