Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On 3/24/2017 11:44 AM, Martin Rex wrote:
> oops, typo:
>
> Martin Rex wrote:
>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com
>> I'm a little confused.
>>
>> This is the cert chain (as visualized by Microsoft CryptoAPI):
>>
>>    server-cert:  CN=cloudflare.com, ...
>>                  contains ECDSA P-256 public key
>>                  is allegedly signed with sha256ECDSA
>>
>>    intermediate CA:  CN=DigiCert ECC Extended Validation Server CA
>>                  contains ECDSA P-384 public key
>>                  is allegedly signed with sha384RSA
>>
>>    root CA:      CN=DigiCert High Assurance EV Root CA
>>                  contains RSA 2048-bit public key
>>                  is self-signed with sha1WithRsaEncryption
>>
>> For those who insist on reading rfc5246 verbatim, this chain requires
>>
>>     ECDSA+SHA384:RSA+SHA384:RSA+SHA1
>       ECDSA+SHA256:RSA+SHA384:RSA+SHA1

I don't think RSA + SHA 1 is actually required.   The Signature over the 
trust anchor (root CA) is basically a no-op - assuming the certificate 
is in the browser(client) trust store.  The trust is traced to the 
public key regardless of the form in which it's provided.  We use 
self-signed certs a lot to carry the public keys and names (and 
sometimes constraints), but that's not required by PKIX.

Mike

>
>> The digital signature on the server certificate looks bogus to me,
>> that should be a sha384ECDSA signature according to NIST, because
>> it uses a P-384 signing key.
>>
>> The signature on the intermediate CA is imbalanced, and
>> should be sha256RSA rather than sha384RSA. (that is only an interop issue,
>> not a security issue).
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>