Hi Andrew,
 >
> I believe the "rsa" cipher does not include padding and
> "pkcs1pad(rsa)" does and now there's also a "pkcs1pad(rsa, <hash
> type>)" that could save as a little more work in the TLS code if we
> only supported TLS 1.2 but can't be used for < 1.2.

I wonder if keyctl can expose the hash for us as well.  Either way, we 
should take advantage of this if possible.

>
>>
>
>>> @@ -943,19 +943,9 @@ static bool tls_rsa_sign(struct l_tls *tls, uint8_t
>>> **out,
>>>                  return false;
>>>          }
>>>
>>> -       privkey_short = extract_rsakey(privkey, key_size, &short_size);
>>> -       tls_free_key(privkey, key_size);
>>> -
>>> -       if (!privkey_short) {
>>> -               tls_disconnect(tls, TLS_ALERT_INTERNAL_ERROR,
>>> -                               TLS_ALERT_BAD_CERT);
>>> -
>>> -               return false;
>>> -       }
>>> -
>>>          rsa_privkey = l_asymmetric_cipher_new(L_CIPHER_RSA_PKCS1_V1_5,
>>> -                                               privkey_short,
>>> short_size);
>>> -       tls_free_key(privkey_short, short_size);
>>> +                                               privkey, key_size);
>>> +       tls_free_key(privkey, key_size);
>>>
>>>          if (!rsa_privkey) {
>>>                  tls_disconnect(tls, TLS_ALERT_INTERNAL_ERROR, 0);
>>
>>
>> Should we be reporting BAD_CERT here?
>
> I'm not sure if you mean BAD_CERT as the second or third parameter but

Third parameter.  Mat took out the code that returned BAD_CERT if 
extract_rsakey failed.  So now if the asymmetric cipher creation fails, 
we have to assume that the certificate is bad (or a configuration issue).

> I don't think we should do either.  Passing BAD_CERT to the remote end
> implies it that it has supplied a bad certificate and the disconnect
> is their fault.  Passing BAD_CERT to our higher layer will imply that
> our certificate is wrong.  In reality the problem here is most likely
> kernel configuration.

Or that the remote has given us a bad certificate :)

Regards,
-Denis