Adapt SHA256 dependency in generate_pkcs7_tests.py

[ronald-cron-arm]

Two proposals to discuss how to unblock #31.

[gilles-peskine-arm]

The caller knows what domain it's in. For example PKCS7 is in the USE_PSA_CRYPTO domain.

[ronald-cron-arm]

That's the difficult part to me actually. I thought it was the legacy domain.

[gilles-peskine-arm]

All of X.509, TLS and PK are in the USE domain. USE and legacy are equivalent for hashes though: both use MBEDTLS_MD_CAN_xxx.

[mpg]

That's the difficult part to me actually.

I think that's the difficult part for everyone :) I was involved in creating these macros and I still need to check from time to time!

All of X.509, TLS and PK are in the USE domain.

I think some parts or TLS 1.3 (those that are not shared with 1.2) are not in the USE domain, but instead always use PSA. But for PK and X.509 yes.

[gilles-peskine-arm]

This feels like it's an extension of psa_information.psa_want_symbol. Maybe even an optional argument
psa_information.psa_want_symbol('PSA_ALG_SHA_256', psa_information.MBEDTLS36.USE_PSA_CRYPTO)?

[ronald-cron-arm]

The optional argument would be the domain of the code for which we want to express the dependency on a given hash, right?

[gilles-peskine-arm]

Yes.

Though on second thoughts the function should not be called psa_want_symbol, because that name already implies a PSA dependency. A new function in test_case.py does sound better, with a domain argument.

[mpg]

As I said on Slack, I think for hashes we can distinguish the domain with:

• things in the PSA or pure-TLS-1.3 domain directly use PSA_WANT or call psa_want_symbol;
• things in the legacy or USE domain use a new helper function.
  (Which is the current state of the PR.)

However that only works because hashes use the same macro for the legacy and USE domains. For other things we're not going to be that lucky. We could have two functions there, but then things wouldn't be uniform.

So, I think I have a preference for a function with a domain argument. Then we don't even need to separate by type of mechanisms (hashes vs cipher vs etc.)

For example:

def psa_or_36_feature_macro(psa_alg, domain36):
    if domain36 = DOMAIN36_PSA or not build_tree.is_mbedtls_3_6():
        return psa_information.psa_want_symbol(psa_alg)

    if psa_alg in hashes_for_36:
        return hashes_for_36[psa_alg]

    if domain36 = DOMAIN36_LEGACY and psa_alg in foo_for_36_legacy:
        return foo_for_36_legacy[psa_alg]
    if domain36 = DOMAIN36_USE_PSA and psa_alg in foo_for_36_use_psa:
        return foo_for_36_use_psa[psa_alg]
    # etc for each family of algs

    raise ValueError

(Or we could have a single dict mapping (psa_alg, domain36) to 3.6 feature macro (which would then need to have duplicated entries for hashes) or any other implementation strategy.)

What I mean is we can have a single function that acts as a drop-in replacement for psa_want_symbol() except it has an extra argument for the 3.6 domain, and I think this has my preference at the moment.

[gilles-peskine-arm]

Gathering information is costly (parsing several files) and should be cached.

But I'm not convinced this actually needs any information about PSA, as opposed to ad hoc text-based rules. We have a fixed set of algorithms that require adptation for 3.6.

[ronald-cron-arm]

Yes that's possible, we could just have a dictionary with PSA_ALG_SHA_... as keys and MBEDTLS_MD_CAN_ ... as values. I am fine with that.

[gilles-peskine-arm]

For the choice of having a helper function or not: I think it mainly depends of what common patterns we have, how many instances of these patterns, and whether we're likely to have more instances in the future. My impression is:

• We have a small number of patterns. At least hashes, maybe PK algorithms?
• The number of instances is small, but larger than 1.
• There's a significant chance that we'll add more instances during the lifetime of 3.6, as we improve test coverage for X.509 and TLS.
• Furthermore the people adding these instances may be unfamiliar with 3.6 complexities, so we should make it discoverable. An optional argument on the PSA-related function is more discoverable than a pattern used in some other test script.

So I lean towards auxiliary functions.

[mpg]

Not quite correct: for SHA3 we want to keep the underscore. I think using a dict would be easier and more readable.

[mpg]

I think the function name should include something like compat36. Also, the description should lead with the fact that it's about 3.6 compatibility: for us it's obvious due the context of the PR, but otherwise "legacy or USE_PSA_CRYPTO domain" in the first sentence will make little sense to future readers as those only exist in 3.6.

[ronald-cron-arm]

#51 has been created that tracks the work to be done, referring to this draft PR but no need to keep it open.