Note that I haven't tested at all, only made sure it builds on my machine.
To be finished tomorrow.

@paulidale, this is a good spot to continue our discussion from #8728

Do we need to think about a case when we have the same name for different algorithms provided by different providers? It can happen by accident or because of misunderstanding.

Wouldnt it be better to have aliases in libcrypto so they can be shared between providers..
It should still be possible to add these aliases into each provider when they are registered.
If a provider wants it own special case aliases then we would also need a list of aliases on the provider side also (Not necessarily embedded in the algorithm table).

Do we need to think about a case when we have the same name for different algorithms provided by different providers? It can happen by accident or because of misunderstanding.

That is always a possibility. In current terms, there's nothing stopping anyone from creating an engine that pretends to implement SHA1, but that does something else. I'm counting on the ecosystem of engines/providers to weed itself out of such "bad apples" (in practical terms, it's about the reliability and popularity if each module, on the responsibility of their diverse authors).

Wouldnt it be better to have aliases in libcrypto so they can be shared between providers..
It should still be possible to add these aliases into each provider when they are registered.

I don't see why it's better to centralize aliases in libcrypto. Thing is that the namemap is shared within a library context, so any alias given from a provider will end up being "global".

However, this made it obvious that the code in this PR isn't quite right. If several providers implement the same algo, but with a slightly different (but still overlapping) set of names, they may not all be added (first such provider wins), or may still be seen as different algorithms (because first given name in each doesn't match). I will fix that later today.

Rethinking where aliases come from, it's true that no one stops us from pre-populating the namemap if we wish... I'll explore that in another PR.

This still feels like the wrong place to do the aliasing. It seems like it is adding complexity (a layer of indirection) that isn't required.

I'm wondering if we need this at all? For the provider internal EVP layer (i.e. FIPS), aliases aren't required. All resolutions are fixed. That leaves libcrypto's EVP interface which handles aliasing already.

We will need an ability for a provider to register a new algorithm name with aliases. No disputing that.

A libcrypto call to convert a name into a canonical form might be worthwhile exporting to providers.

If we do want aliases inside the providers, the core name map can be modified to handle multiple names mapping onto a single integer and this complexity is avoided. The reverse map from integer to name could be to the canonical form (or first registered or whatever).

BTW: I think we're also risking the loss of case insensitive look up of algorithm names.

This still feels like the wrong place to do the aliasing. It seems like it is adding complexity (a layer of indirection) that isn't required.

Not sure I follow. Aliases are names, right? So how can it be wrong to handle that where names are handled?

I'm wondering if we need this at all? For the provider internal EVP layer (i.e. FIPS), aliases aren't required. All resolutions are fixed. That leaves libcrypto's EVP interface which handles aliasing already.

No it doesn't (apart from case insensitivity). That's why the namemap came to be, so we'd avoid involving the object database.

We will need an ability for a provider to register a new algorithm name with aliases. No disputing that.

A libcrypto call to convert a name into a canonical form might be worthwhile exporting to providers.

What would the provider do with that? Also, what is "canonical form"? I'm actually trying to get away from the idea that there is one true name, and rather see that all names for an algorithm are "equal".

If we do want aliases inside the providers, the core name map can be modified to handle multiple names mapping onto a single integer and this complexity is avoided. The reverse map from integer to name could be to the canonical form (or first registered or whatever).

That's what I am trying to do on the API level. The internal structure is a what it is, and it needs being reworked to allow adding more names for the same algo (i.e needs a bit more flexibility)

BTW: I think we're also risking the loss of case insensitive look up of algorithm names.

I forgot that we decided this. This might be subject for a fixup PR

That's what I am trying to do on the API level. The internal structure is a what it is, and it needs being reworked to allow adding more names for the same algo (i.e needs a bit more flexibility)

What about adding:

int ossl_namemap_alias(OSSL_NAMEMAP *namemap, int number, const char *alias)

or maybe allow an array of aliases instead of one?

The usage being:

int n = ossl_namemap_add(namemap, "foo");
ossl_name_map_alias(namemap, n, "bar");

Not sure I follow. Aliases are names, right? So how can it be wrong to handle that where names are handled?

I'm starting to wonder where OIDs will be dealt with? They are essentially names of a different format. I'm assuming libcrypto will map an OID to exactly one name. A provider will need to register that name or face badness. This all smells like canonical.

I think this also implies objects.txt will remain in libcrypto and thus the algorithm aliases are known to libcrypto. Providers don't need to know about them if so.

objects.txt isn't the only source of aliases. It's main intention is to map OIDs to names, and I would say that either way, a provider that wants to have its implemented reached through an OID will have to use a matching name (among all the names they can use).

This is obviously not just a technical discussion, but also one of principle: who shall have the power and the responsibility to decide what names an algorithm implementation shall have? My vote goes to providers.

Perhaps a conference call is in order about this?

Perhaps a conference call is in order about this?

Sure.

Let us think of the users and application writers. If aliases are part of the provider, then it is quite possible that different systems could have conflicting aliases. For example, someone may use GOST as an alias, whereas someone else will use the more official name GOST-2018 or some such. This means that applications could break at run time when moved to a different system. That would be very bad.

For this release, it seems that the simplest way to prevent this from happening is to have aliases only defined and supported in the core. We would be hoping that providers only use standard or official names, and that those names are "enforced" by standards organizations, nations, or other third-party. This does not completely solve the problem, but it is probably good enough for a first release of the module architecture, and it has worked well enough so far in OpenSSL history; look at the comparatively small number of aliases.

You can always add this later. You cannot remove it later if added now. Wait to see what developers of providers need and want, first.

So if I understand correctly, we do want multiple names (i.e aliases) somehow. So, right, if not implemented as part of the namemap API (which is majorly what this PR is about), then how? Remember that we're banning asn1 code and thereby the object db from the fips module.

It seems to me that this effort is needed somehow, even if we don't give the providers the opportunity to specify multiple names.
(BTW, if we are to give them the possibility some day, how do you propose to do that? It can obviously not be via the algorithm specification structure, 'cause that will break the API, unless we make that change before releasing 3.0)

Maybe you do want multiple names. My suggestion is you wait until after you get some experience and interaction with the community and see what they want/need, not just the couple of people from the OMC in this discussion.

FWIW, my preference would be for an API providers could call to add aliases for official names, and to support that in the config file. But, again, not for this release.

@richsalz, you said you wanted aliases defined in libcrypto. That can actually done by pre-populating appropriate namemaps... Or are you suggesting another mechanism?
I'm frankly kind of lost by what you're saying, 'cause you want some kind of alias support (in libcrypto at the very least), but I don't see what mechanics you want to be able to provide that.

I guess I was using shorthand that could be misleading; sorry about that.

Aliases should be defined in the core, as part of the release. Just the way they are now. Do not let providers add their own aliases; they can only use a single new name (and you have to cross your fingers and hope it's an official name defined somewhere), or they can use an existing name defined by OpenSSL. [That argues there should be a way for a provider to query the core if a crypto mechanism name is known or not.]

Later on, after there's more experience and a better understanding of what is actually needed, then allow run-time aliasing, provider-set aliases, etc.

Is that more clear?

Aliases should be defined in the core, as part of the release. Just the way they are now.

"the way they are now" means using the object db, which means dragging in asn1 code, which we try to avoid.

I guess my "more clear" comment still wasn't clear enough. Do not allow providers to register aliases. They are defined in the core, when the core is compiled. Relax that restriction in a later release.

So uhmmm, are you saying that crypto/evp/evp_fetch.c should use the object database when it isn't built for the FIPS module, and namemap when it's built for the FIPS module? Is that what you're getting at?

I'm not looking forward to the added FIPS_MODE guards, I gotta say that.

Can this not be handled in the same way that crypto_malloc, etc., are done?
Or pull the object database stuff out of the ASN1 code. Want me to try that?

The object database uses ASN1_OBJECT, and that's part of its API...

Travis failure is relevant (doc-nits).

Fixed

Rebased on fresh master.

Ping

Merged with last nits fixed.

a9550b7 OSSL_NAMEMAP: make names case insensitive
734a462 Add a namemap test
651d441 Replumbing: add support for multiple names per algorithm