> On Nov 5, 2018, at 10:18 PM, Alice Wonder <al...@domblogger.net> wrote:
>
> if not using keyUsage but using extendedKeyUsage within req_extensions should
> digitalSignature be used?
>
> I basically do the following for my postfix certs
>
> [req]
> distinguished_name = dn
> req_extensions = ext
> prompt = no
>
> [dn]
> CN = ${FQDN}
>
> [ext]
> basicConstraints = critical,CA:FALSE
> extendedKeyUsage = serverAuth,clientAuth
> subjectAltName = @san
>
> (obviously with any alternate names in [san]
This is perfectly fine. And "digitalSignature" is only a "keyUsage" bit,
extendedKeyUsage is about higher-level application purpose "OIDs", not
the basic keyUsage bits.
A typical RSA certificate from a CA will have (using the equivalent
OpenSSL value names):
keyUsage = keyEncipherment, digitalSignature
extendedKeyUsage = serverAuth, clientAuth
Now the "keyEncipherment" bit is a concession to legacy interoperability,
and is perhaps no longer wise. You get better resistance to some attacks
by going with just "digitalSignature", provided you're willing to forgo
RSA key exchange. However, there are likely still various sending MTAs
that don't support PFS (DHE/ECDHE) ciphers, and disabling RSA key exchange
in MTA is likely premature.
Check your logs for evidence of TLS <= 1.2 ciphers that don't have
"AECDH", "ADH", "ECDHE" or "DHE" in their names. On my personal domain
I see in recent logs:
22850 ADH-AES256-GCM-SHA384
2425 ECDHE-RSA-AES256-GCM-SHA384
804 AECDH-AES256-SHA
382 AES256-GCM-SHA384
368 ECDHE-RSA-AES256-SHA
293 ADH-AES256-SHA
234 DHE-RSA-AES256-GCM-SHA384
160 ECDHE-RSA-AES256-SHA384
158 DHE-RSA-AES256-SHA
39 DHE-RSA-AES256-SHA256
1 ECDHE-RSA-AES128-GCM-SHA256
No inbound connections out of ~27k that use non-PFS RSA key transport.
So it sure looks like I'd not cause any cleartext downgrades or other
problems by listing a keyUsage of just "DigitalSignature".
That said, most client likely don't enforce the keyUsage, so it is
likely to not matter much yet. Just something to keep in mind as
things evolve...
--
Viktor.
P.S.
FWIW, my inbound TLS 1.3 connections are pretty much all from freebsd.org
mailing lists:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
here we don't see "DHE" or "ECDHE" in the cipher name, because TLS 1.3
ciphers are defined and negotiated separately from signature algorithms,
so the cipher name does not say anything about which asymmetric algorithms
were used for key exchange and authentication.
The only other use of TLS 1.3 is from a couple of "iDevices" in the hands
of two of my submission users, so some Apple software is doing SMTP
submission with TLS 1.3.
