Rebased, but needs more work, since provider code has moved around a lot

@slontis and I discussed this recently. I'm not sure this is a great path to follow -- making all names into arrays of names seems like it is needlessly complex. Using a single name should be the norm.

We were thinking along the lines of using the object database so that the core can populate aliases automatically (i.e. if the name matches either SN_XXX or LN_XXX, add both). The core needs the object database regardless, so there is no waste there and it allows providers to not have to worry with aliasing.

Well almost, there also needs to be a way for a provider to add aliases -- I'm thinking an explicit function that adds an alias (or aliases) for an already defined name.

Contrary to you, I claim that the new core has zero need for the old method object database. The namemap replaces it.

Something I also realised is also that we shouldn't copy the name string when creating new method instances, but rather the namemap id. That means that we can easily support multiple names there without having to duplicate a whole darn array.

Regarding pre-populating the namemap, see #8984

OIDs still depend on the object database....

Yeah, but the new core doesn't use OIDs, at all. It just uses names.
We will still need to do OID to name translation and therefore have a OID<->name db, but that's a separate thing. (and sure, we can add OID support, and probably should, but we don't have that right now)

What about restricting each algorithm to a single name and having the core know about some aliases for backwards compatibility? It isn't like we need to have multiple names for things, they are handles to access algorithms as far as the core is concerned.

This would let us clean up some of the mess (e.g. id-XXX algorithms).

If a provider really does want the same thing registered under two names, it can register it twice. It will get different IDs but they're not publicly visible or terribly meaningful (unlike NIDs).

What about restricting each algorithm to a single name and having the core know about some aliases for backwards compatibility? It isn't like we need to have multiple names for things, they are handles to access algorithms as far as the core is concerned.

Just about everything is registered with 2 names currently in the old system (SN and LN)

The two names are often not distinct when looked up case insensitively.

What about restricting each algorithm to a single name and having the core know about some aliases for backwards compatibility? It isn't like we need to have multiple names for things, they are handles to access algorithms as far as the core is concerned.

That's essentially what #8984 does (why not have a look?)

I was more thinking of having the core's EVP layer handle the mapping and not duplicating names all over the place in different name maps. The effect is similar though.

I think we can rely on providers to use the canonical name for each algorithm but not application code. The former is new and we can define the rules, the latter is legacy and the rules escaped long ago.

I was more thinking of having the core's EVP layer handle the mapping and not duplicating names all over the place in different name maps. The effect is similar though.

Ah, so actually exactly the same, just different spot...

I think we can rely on providers to use the canonical name for each algorithm but not application code.

... I think we need a zoomed out (i.e. not just technical) discussion on this.
What's the "canonical" name? Who's the authority that decides this?

Just to take an example that we have in our code, scrypt. According to the ASN.1 module in RFC 7914, it goes by "id-scrypt":

   id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11}

We would like to call it just "SCRYPT", because that conforms better with the rest of the names we use, right?
So what would be the "canonical" name, "id-scrypt" or "SCRYPT"? On whose authority? Yours? Mine? RFC 7914's?

So, as a way to avoid that kind of dispute, why can't we simply think in terms of a set of names, all equal?

Back to the more technical side of things:

• the new namemap already supports a set of names without making any of them "canonical". They simply get the same identity number.

A more personal note:

• I loathe the notion of having an implementation in one corner of the code and the names it goes by in another corner. Having them together in code, like this PR does, avoids having to find the implementation in one spot and then having to go look elsewhere to find the name(s) it goes by. (Yes, I know that's what we currently do... :-/)

I was more thinking of having the core's EVP layer handle the mapping and not duplicating names all over the place in different name maps. The effect is similar though.

Ah, so actually exactly the same, just different spot...

Oh, wait, I forget... #8984 does exactly that!

Rebased and cleaned up to match the changes that have been made re name vs name_id.

This almost tests right... only test_sslapi acts up, still.

Speaking of this, I realised there's really no reason why this PR and #8984 should be alternatives for each other... they should actually combine perfectly well.

Ah, figured the last failure out... I had mixed up certain names with each other.
(some ciphers with different key sizes are in 256, 192, 128 order while others are in 128, 192, 256 order... when cutting and pasting a bit and getting in a flow, it's no wonder I didn't get it right in some places...)

This is, btw, no longer WIP

Rebased the lot too

@mattcaswell, compatible naming is main reason I wanted the core to add the aliases it knows about. #8984 will achieve this. I wanted to write consistent naming, but it isn't currently.

As for providers listing several names for an algorithm, I see this as unnecessary if the core knows them. One should be enough. This has been a sticking point between me and @levitte 😀

We have to trust that the providers will do the right thing (whatever that is). A typo in a provider's name list for an algorithm could cause problems like the one suggested -- there is no nice mitigation. The best I can think of is to: insist that the names must either be all unknown or all known and referring to the same algorithm. i.e. no additional new names are permitted for algorithms the core knows about.

[edit: bolded the suggestion, I woudn't mind seeing this implemented]

I think you're making a problem where there isn't one, or rather, you're making it our problem when it's really somebody else's. And most of all, it's a social problem, not a technical one.
The basic message here is "know your providers" (for anyone who wants to use them), but also "know the expectations" (for the provider writers).

To put it quite plainly, this has two sides:

1. if someone writes an application, or configures for a provider that doesn't provide algorithms with the names they expect, they should investigate what the configured providers does use. This is a use case for the openssl provider tool and why that tool is important.
2. if someone writes a provider and wants to implement some well known algorithms, it would be wise of them to use at least one or two well known names, or face a reality that their provider will probably not grow very popular.

Something that I don't want to see is us becoming some kind of registry of all names possible, including for whatever upcoming algorithms. I believe that could become an unnecessary hurdle. I know that's not quite what you're proposing, @paulidale, but that's a possible consequence that we have already seen (we've become the central registry of NIDs and associated names).

The configuration problem that's been mentioned is just same as configuring for using the FIPS module only, and having an application that tries to fetch, say, the "sm3" hash algo. That will fail because it's not available. The FAQ should be "Did you check that this providers provides that name?"

I'm not worried about malicious providers -- they lie beyond our control. I'm worried about a provider that, for example, registers CAMELIA-256-CBC:CAMELLIA256 and the bad name then being saved in a configuration file.

I guess the core of the message is know your providers as @levitte wrote.

My suggestion was probably a bit extreme after all.

BTW, if we're inventing a naming standard for our names, maybe we should document it in some sane place other than a comment in the code. Please suggest.

How about: doc/internal/man7/the_naming_of_cats.pod :)

I agree it should be documented, either as a README or a POD file. I lean towards the latter.

I kind of think that the FIPS provider could get away with just defining the names NIST uses.

YES!!!

So, er, what is the NIST name for AES-265 in CBC mode? SP 800-38A doesn't help much, unless you wanna see names like CBC-AES256...

I'll take that approval. Should someone want to make name changes, do so in another PR.

Merged.

695d195 Replumbing: make it possible for providers to specify multiple names
df553b7 Adapt existing providers to posibly have name lists