Sorry for the fuss, I think I was confused. Now my interpretation of the draft is as follows.
A server is expected to send a Certificate message that contains certificates using the signature algorithms specified by the client, with preference and exception rules defined in section 4.2.3 (Signature Algorithms) and 4.4.1.2 (Server Certificate Selection). A server is expected to generate a Certificate Verify message using a method that is in the intersection of the algorithms specified by the client using the Signature Algorithms extension that is _not_ blacklisted to be used for signing CertificateVerify. The blacklisted ones are: rsa_pkcs1_XXX and those use SHA-1 (rsa_pkcs_sha1, dsa_sha1 ecdsa_sha1). note: It seems that dsa_sha1 and ecdsa_sha1 have _RESERVED suffixes in A.3.1.3 even though they are referred to without the suffixes in the document. Is this an editorial issue? I think I got confused by the way section 4.4.2 (Certificate Verify) blacklists the algorithm. To me the following sentences seemed to indicate that PKCS1 and SHA1 needed different treatments. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". SHA-1 MUST NOT be used in any signatures in CertificateVerify. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. But now to me it seems that both PKCS1 and SHA1 are allowed to be used in Certificate message only (to provide support for legacy certificates). Considering that, to me it seems preferable if the draft stated that both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in certificates. Or is there any need to handle PKCS1 and SHA1 differently in protocol implementations? Thank you in advance. 2016-10-14 13:38 GMT+09:00 Kazuho Oku <kazuho...@gmail.com>: > Hi, > > In TLS 1.3, my understanding is that the digest function negotiated > using the Signature Algorithm should be used for generating > CertificateVerify, since the draft states that: > > | Each SignatureScheme value lists a single signature algorithm that > the client is willing to verify. > | (section 4.2.3) > > | The Hash function and the HKDF hash are the cipher suite hash > algorithm. Hash.length is its output length. > | (section 7.1) > > The draft permits fullbacking back to using SHA1 certificates: > > | TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no > valid certificate chain can be produced without it. > | (section 4.2.3) > > However, the draft also states: > > | SHA-1 MUST NOT be used in any signatures in CertificateVerify. All > SHA-1 signature algorithms in this specification are defined solely > for use in legacy certificates, and are not valid for > CertificateVerify signatures. > | (section 4.4.2) > > So my question is, which signature algorithm am I supposed to use for > a rsa_pkcs1_sha1 certificate? I'd assume that the answer is > rsa_pss_sha256, but I could not find any such indication within the > draft. > > -- > Kazuho Oku -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
