add various const specifiers to pk utils

[bl4ck5un]

This allows const pointers to secret keys in functions such as mbedtls_ssl_conf_own_cert. Related to this forum discussion. Also related to RP #1004.

Notes:

• Done: The submitter has accepted the online agreement here with a click through.
• Done: The PR follows the mbed TLS coding standards.

[RonEld]

Hi @bl4ck5un Thank you for your contribution!
Note that since this is a change in API, so it won't be inserted until there will be a major release, assuming we agree to adopt this change.
In addition, unfortunately we cannot accept contributions without a signed CLA. Could you please refer me to the CLA you have signed?

[bl4ck5un]

I've signed this contributor_agreement. I signed under username v0ido9.

[RonEld]

Thank you for your confirmation

[mazimkhan]

retest

[mazimkhan]

@bl4ck5un can you please rebase you PR to development head. There have been some fixes in development branch to stabilise the timing tests.

[bl4ck5un]

@mazimkhan rebased my commit on f3ada4a

[simonbutcher]

Hi @bl4ck5un,

We've discussed adoption of this PR, and whilst it makes sense, because it introduces const across the API, it's difficult for us to merge as it would break source level compatibility with our existing API for users already using the library. That doesn't mean we don't want to make these changes, just that the timing should be right, and we should do it in a big API breaking release. Maybe Mbed TLS 3.0.

As such, we're not going to merge this PR soon, and by the time we may get around to it, the PR may be outdated.

Therefore, @k-stachowiak has raised this as issue #1485, which records this PR, and when we get to a point in the lifecycle of the library where we can make these changes, we'll revisit this, and may use this PR.

Rather than keep this PR open indefinitely, I prefer to close it now, and revisit this area at a later time when we look at #1485.

Thanks for your support of the project and this contribution. We do want to adopt these ideas and changes, but as I say, the timing has to be right.

[mpg]

While I tend to agree with the part that adds const for key writing functions, I have more mixed feelings about adding const to things like pk_sign(): actually, pk_sign() can modify the state of the private key context in some cases (for example, updating blinding values for RSA).

Now technically the const would still be correct, as in C const is not "deep": it only means we don't modify the members of the structure, and we're allowed to modify the objects pointed to by members of the structure (which again, at least pk_sign() does, at least with RSA), but "morally" I'm not sure I feel comfortable adding const here as I'm afraid it might give the wrong impression. This impression could matter when it comes to questions such as "can I make concurrent calls to pk_sign() from various threads using the same pk_context?" Currently the answer to that question (for RSA) is "not unless you built Mbed TLS with MBEDTLS_THREADING_C enabled (which it isn't by default)". Making the function accept a const pk_context * might make it look like the answer is yes, which it isn't (in the default build).