Subject: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?

From: Kazuho Oku <[email-masked]>
Date: Fri, 14 Oct 2016 13:38:37 +0900

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 14 Oct 2016 14:34:49 +0900

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.

-- 
Kazuho Oku

---

From: Hubert Kario <[email-masked]>
Date: Fri, 14 Oct 2016 17:15:48 +0200

> differently in protocol implementations?

there isn't, the only case is when you also implement TLSv1.2

Pure TLSv1.3 implementation shouldn't ever generate messages or try to verify 
messages signed with SHA-1 (or MD5 for that matter)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 14 Oct 2016 18:43:27 +0300

> messages signed with SHA-1 (or MD5 for that matter)

Unfortunately while one sees less and less use of SHA-1 as certificates
expire, there still is use of SHA-1 in OCSP. The only place where my
TLS library uses SHA-1 is with OCSP.

-Ilari