The definitions are very precisely defined in the section that you link, pointing to specific functions in the RFCs that define them and mapping all inputs and outputs appropriately. Developers who don't know what the strings mean will just be using a library to do it. Developers who need to know what the strings mean will be reading these paragraphs that define what the strings mean in precise detail. Your proposed solution does not change this aspect.

We moved away from the previous approach of a simple description of what algorithm to use to this more complete version to solve exactly this problem, and we have vetted this approach with cryptographic experts.

As for other algorithms, they can be defined using the registry like these others are. That can happen either in this core if anyone wants to step up and propose a precise definition like the others, or that can happen in its own standalone spec.

Additionally, I want to point out that the algorithm no longer needs to be explicitly signaled in the signature parameters. If the application in question has its own way of determining the signature method, then that can and should be used instead of the alg parameter, which exists for the use cases that need runtime signaling of algorithm agility.

See also the note in #1515 that you aren't parsing the algorithm string and pulling out sub-pieces, but are instead using the whole thing as an identifier. So a developer will never need to know the difference between the strings pss and 1_5, but will need to know what functions to call when they see rsa-pss-sha512 and rsa-v1_5-sha256 as complete strings.

The definitions are very precisely defined in the section that you link, pointing to specific functions in the RFCs that define them and mapping all inputs and outputs appropriately.

Yes, this is good, no issue with this.

See also the note in #1515 that you aren't parsing the algorithm string and pulling out sub-pieces, but are instead using the whole thing as an identifier.

Yep, understood... but not the point of contention.

Developers who don't know what the strings mean will just be using a library to do it.

If history is any indicator, these complex strings are going to be exposed to developers, and that's the mistake we don't want to repeat again.

Developers who need to know what the strings mean will be reading these paragraphs that define what the strings mean in precise detail. Your proposed solution does not change this aspect.

Yes, and that's fine (and not the issue).

We moved away from the previous approach of a simple description of what algorithm to use to this more complete version to solve exactly this problem

Yes, that particular aspect is an improvement, and again, not the issue.

and we have vetted this approach with cryptographic experts.

Ahh, the good 'ol appeal to authority. :)

Which experts? Did this happen publicly? Where is the record of the conversation? What exactly was discussed? The response here seems to indicate the discussion didn't involve the point of contention.

Also remember that "cryptographic experts" have traditionally picked names like "ed25519" and "xchacha20-poly1305" -- which are... not very helpful. "AES" is pretty good... "Advanced Encryption Standard"... slap a date on the end of it (to parameterize it with a human-meaningful identifier) and even "non-experts" can get an idea of what it's about. That's the point of contention. Don't introduce cryptographic parameters that are almost certainly going to be exposed to developers without making them accessible to non-cryptographers.

As for other algorithms, they can be defined using the registry like these others are. That can happen either in this core if anyone wants to step up and propose a precise definition like the others, or that can happen in its own standalone spec.

A few questions on how that registry is maintained:

• Can an algorithm be registered from an I-D? Is a final RFC required for registration?
• Are aliases allowed? Can "ecdsa-2013" refer to "ecdsa-p256-sha256"?
• What is the appeals process (when there is disagreement with the Experts)?

I'll note that the following text applies from https://www.rfc-editor.org/rfc/rfc8126#section-4.5

Required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request. It is also a good idea to include, when possible, a sense of whether many registrations are expected over time, or if the registry is expected to be updated infrequently or in exceptional circumstances only.

That text is missing from the spec currently and I expect will need to be added if this is going to be an "Expert Review" sort of thing.

Some of the conversation has happened publicly and some with direct conversations with the editors, but most recently we reached out to the CFRG for input into defining PSS parameters specifically:

https://mailarchive.ietf.org/arch/msg/cfrg/YHkZVX3sZrpJG2wZl6LyYv9R7CA/

What's more important is that the text is public here and can be viewed and discussed in the WG. To that end, are you proposing that rsa-2005 is just more understandable and descriptive than rsa-pss-sha512? I really disagree on that, the value of "2005" gives no hint to a developer what they're doing. Are you instead proposing that we remove the paragraphs about how the registered signature methods are defined? I deeply disagree with that, if that's the case -- anything that's registered needs to be clearly defined with all of its parameters.

The publicly available text also includes the IANA registry guidelines, which as you note isn't finalized yet. If you'd like to propose a PR to fill this portion out now, please do, it would be very helpful! The registration and review process is defined by IANA and guided by the text of the document that defines the registry (and documents that update that). It will likely be some combination of specification-required or expert-review. I am very doubtful that an I-D would ever be sufficient for registering a value though, because of things like this: https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-draft-13

Are you instead proposing that we remove the paragraphs about how the registered signature methods are defined?

Definitely not this as spelling it out in more detail was an improvement to the specification; spelling this sort of thing out in excruciating detail that leaves no room for interpretation is a good thing.

To that end, are you proposing that rsa-2005 is just more understandable and descriptive than rsa-pss-sha512?

Not more descriptive, no... more understandable by a broader audience... maybe.

I'm saying that trying to pack more information into the identifier is going to make it less understandable to a broader audience. Adding the details of the input functions are not useful to most developers (because they don't know what those inputs mean). I'm saying that rsa-pss-sha512 is not descriptive enough and you'd have to go even further to encode the other parameters so someone actually knows what they're using by looking at the string. Your email to CFRG is a perfect example of the issue here, specifically this one:

https://mailarchive.ietf.org/arch/msg/cfrg/4ETFcMKXTWp8e6mlcnVLlku3TAk/

So, is the solution to make the entire string parameterized, or to cause people to go and read the actual parameters because they're not encoded in the string? For example, why aren't you encoding the MGF and the salt size -- rsa-pss-sha512-mgf1-salt64?

I really disagree on that, the value of "2005" gives no hint to a developer what they're doing.

2005 at least tells them that "this stuff is from 2005, so you might want to look up newer stuff." The date stamp makes that more obvious.

sha512-mgf1-salt64 (and other parameters) are even worse, most developers have no idea what appropriate values are there... you have no idea if it's modern stuff or outdated. Is that SHA2-512 or SHA3-512?

What might be better is:

rsa-2003
rsa-2005
ecdsa-2013
eddsa-2015
hmac-2006
recommended-signature-2015 (aliased to eddsa-2015... or just this value -- no aliases)
recommended-nist-2013 (aliased to ecdsa-2013... or just this value -- no aliases)

.. or equally human-readable-ish values (towards the bottom).

The publicly available text also includes the IANA registry guidelines, which as you note isn't finalized yet. If you'd like to propose a PR to fill this portion out now, please do, it would be very helpful!

Yes, happy to do that once we agree on what to put there... for example, no one wants this:

I am very doubtful that an I-D would ever be sufficient for registering a value though, because of things like this: https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-draft-13

... but being able to register something provisionally is probably a good thing.

Also, if we're going to insist on algorithm strings that look like this: rsa-pss-sha2-512-mgf1-salt-64 ... then I'll probably insist on being able to define aliases in the registry... but ideally, we avoid the whole "aliases in the registry" thing by agreeing on identifiers that might be useful to non-security engineer developers (like people that end up using JWTs, for instance).

So, let's say registration needs to be:

• For provisional registrations - I-D required plus expert review to make sure the spec references things that look like they have been implemented.
• For permanent registrations - RFC / W3C REC or equivalent required
• Aliases are allowed? (I expect this to be contentious)

Thoughts?

I don't agree with your stance at all. I strongly believe that making the changes you suggest will make it more difficult for developers trying to implement this specification with these algorithms.

The strings are not intended to be fully parameterized as you suggest they could be -- we do not want people parsing the string and treating it as parameters. The identifier should be unique and descriptive enough to a developer to make sense of the reference but also not have overlap with other things that are registered. "RSA2005" doesn't tell me anything useful at all, and while I know you see that as a feature, I see that as terrible for developers. I would sooner have "rsa-pss" and "rsa-v1_5" as fixed values with the current function definitions, but the hash function is an independent part of the algorithm already that it makes sense putting in the identifier, in my opinion. The inclusion of years is just obfuscating the definitions and I think this is bad practice that should not be continued.

Can you please explain to me what the cost for using rsa-pss-sha512 AS A STRING is for a developer? As I said before, developers will simply copy and use these values as-is. Our job is to make them reasonably descriptive, enough to recognize even to non-cryptographers. The identifiers could in fact just be "a", "b", and "c", but I think this are almost as bad as "rsa2005" and the like. :)

I don't see how my message to the list about the algorithm definitions supports your case, as the question to the list was about the function parameters that get called in code and not about the identifiers used in the optional field. Since the identifiers are not parameterized, the discussion on the list is not germane to your point. The identifiers were never under discussion in the thread.

I personally don't think aliases in a registry like this are a good idea either. What's the point of having more than one string to reference this? Yes, if we made the strings ridiculously long, as in your strawman, then it might make sense -- but we aren't doing parameter strings.

And finally, remember that the algorithm parameter is OPTIONAL and is only needed for when you're doing runtime signaling of registered algorithms between parties. If two parties have some other mechanism for determining the algorithm, as laid out in the spec, they can use that mechanism. In which case, the algorithm parameter isn't relevant anyway and this argument doesn't apply.

The purpose of the registry is to have stable values and behaviors associated with the code points those values occupy. When someone writes code that uses a value from the registry, that code should be expected to do the right thing and the same thing over time. Provisional registrations happen all the time as specs near completion, which is part of defining the IANA process. But that's not the same as wanting to register a value and point it to a webpage instead of a specification -- which is exactly what an I-D is that's not in the standards track. I'm not sure what you're worried about solving here, to be honest.

Let me be clear: I'd be fine with picking better names for any of the registered parameters, but what's been proposed here is not better.

It seems like it'd be helpful to discuss this briefly in the WG meeting, to get a sense of others' opinions.

In the meantime, please keep this issue limited to the topic of the naming convention for these values; if we need separate issues for registry policy, aliases, etc. those can be created.

In case you need a third opinion from someone familiar with the space, I think that @jricher is right about the definitions being adequate. I'd want to see a much stronger argument in favour of a change.

The current design is hard to read in some ways (e.g., algorithm identifiers are not mentioned in the algorithm definitions, notation is not consistent) but I believe that the design is fundamentally the right way to do signing. That is, each algorithm uses a very narrow profile with no parameterization. The specification explains how to take keying material and generate a signature from a message or verify a message given a signature for each algorithm.

At some level, the idea that you might call RSA-SSA PKCS#1v1.5 with SHA-256 something simpler is appealing, but the unwieldy name is just an opaque string. Better that the string match existing expectations about algorithm names.

I wouldn't know what rsa-2003 is without looking it up. Worse, that naming convention implies a linearity that just doesn't exist. For instance, Lamport signatures are very old, but they also happen to be very secure (more secure than ECDSA under certain assumptions even).

Finally, we've generally given editors discretion regarding names. Given that the editor in this case has chosen a well-understood and recognizable naming convention, we should respect that.

This issue has branched out into all sorts of adjacent territory. Let's try to keep each issue to a single topic.

@mnot wrote:

It seems like it'd be helpful to discuss this briefly in the WG meeting, to get a sense of others' opinions.

I hope that if you decide to do this, you will have people there that can present both sides of the argument. I'm happy to show up if there is a time and place specified. :)

if we need separate issues for registry policy, aliases, etc. those can be created.

Created issue #1537 and issue #1538

@jricher wrote:

The strings are not intended to be fully parameterized as you suggest they could be -- we do not want people parsing the string and treating it as parameters.

I know, and that's not the point of contention.

remember that the algorithm parameter is OPTIONAL and is only needed for when you're doing runtime signaling of registered algorithms between parties.

Yes, but we're discussing what happens when the algorithm parameter is used. That it is optional (which is also problematic) is beside the point.

@martinthomson wrote:

I believe that the design is fundamentally the right way to do signing. That is, each algorithm uses a very narrow profile with no parameterization.

Yes, agreed, and that's not the point of contention either.

At some level, the idea that you might call RSA-SSA PKCS#1v1.5 with SHA-256 something simpler is appealing, but the unwieldy name is just an opaque string. Better that the string match existing expectations about algorithm names.

It's not just an opaque string to a developer using a library that implements this specification. It absolutely will be exposed to them just like JOSE exposes all sorts of parameters that most developers are ill prepared to pick. They will read meaning into it, or even worse, implementers and developers that know what those parameters mean won't actually have all of the parameters in front of them and will have to go and read about the algorithm anyway to understand what all of the parameters are.

I wouldn't know what rsa-2003 is without looking it up.

Yes, that's exactly the point, you should be looking it up if you really need to know. If you're too time constrained to do so, you can just use the latest date you can find and be fairly certain that you're not footgunning yourself.

Worse, that naming convention implies a linearity that just doesn't exist. For instance, Lamport signatures are very old, but they also happen to be very secure (more secure than ECDSA under certain assumptions even).

Then pick a different, more modern date for a lamport signature scheme.

Finally, we've generally given editors discretion regarding names. Given that the editor in this case has chosen a well-understood and recognizable naming convention, we should respect that.

Appeal to authority; no thank you. :)

I was the primary editor of this specification from 2013-2020... we had this naming convention for 7+ years, and it was just changed relatively recently... but the fact that I was an Editor of this specification for that long shouldn't have any bearing on the discussion.

What should probably matter more is that my company (Digital Bazaar) does create cryptographic software for developers, for example node-forge which has 647M+ installs per year (that is not a typo). Many of these developers do not have the expertise to understand these parameters or strings and repeatedly pick dangerous parameters or think they know what they're picking when they don't. So, we're very aggressively trying to limit their options while providing some limited cryptographic agility. Our experience is that exposing strings like rsa-pss-sha512 and rsa-v1_5-sha256 result in confusion, with support requests to the effect of: "What should I pick? What's the difference." -- in those instances, which are the majority of instances, a year in the string results in far less confusion, where things like rsa-v1_5-sha256 results in more confusion.

This is also a strategy that has worked well in the Linked Data Signatures work: https://w3c-ccg.github.io/security-vocab/#classes

Date-stamping algorithm identifiers has resulted in our customers understanding when something is out of date and when they should move on. This happens automatically these days vs. us having to prod every one of our customers off of old crypto.

These are the concerns I'm bringing into this thread. These are not opaque strings we're talking about... "jf89Z3k" is an opaque string... what we're proposing here are human-readable strings, and ones like rsa-v1_5 vs. rsa-pss won't confuse implementers, but they will confuse developers... and if history is any indicator, the implementers will expose these strings to developers (which is where the trouble starts).

@mnot Yes, this topic (and general parameter bikeshedding) was one of the topics I was planning to bring up at the meeting, I'll make a special point of it.

@msporny I'm confused as to why you'd say that the I-D spec that you worked on used the date format for signatures, since nearly all revisions used values like rsa-sha256. Only the final two versions added hs2019, which wasn't an algorithm specification at all and was functionally a null value telling the developer to go look at the key material and figure out what algorithm to use. Because of this I'm also confused as to why you'd say that making an explicit algorithm parameter optional is problematic, since this is exactly the behavior that hs2019 patched into the old draft.

Naming is hard -- as we all know. I think we all want the best names -- for some definition of "best". I presume we all also weigh how long we want to spend on naming relative to how much trouble we think those names may get us (or others, really) in the future.

Here are my thoughts on naming algorithms based on a functional perspective:

What use is a name?

1. Distinguishing a thing from other things.
2. Providing a common, shorter reference for a distinct thing.

Some types of people we know will be involved in using software here:

1. Implementers
2. Users (developers that use the implementers' software libraries)

With respect to algorithms, what differences are important to implementers?

1. All of them. Implementers must understand all of the details to properly implement an algorithm.

What about users?

1. Which algorithms they can find implementations for / which algorithms their desired implementation supports.
2. Which algorithms are "the best" for their use cases.
3. Which algorithms are still "the best" when auditing/maintaining older code.

How should users decide which algorithms are "the best"?

Depends on their level of expertise: Are they experts (who can understand the internal differences of algorithms) or are they not (they only need to trust an expert's opinion of "the best" algorithm to use)?

If an algorithm identifier does not capture all of the details of a particular algorithm (I presume it will not as it's a short name), when would:

Implementers need to look up the details?

Always. In order to implement properly.

Expert users need to look up the details?

Always. In order to decide which to use.

Non-expert users?

Never.

What should a name communicate to a non-expert user?

Whether or not the algorithm is expert-approved and a signal for when it was expert-approved or whether this may have changed. Potentially which expert(s) approved it may also be useful. If there's a higher-level function that non-experts need to understand then this could also be present in the name (e.g., Do I use a shared key or public/private keys with this algorithm?).

Do non-expert users ever see algorithm names? Are they for non-expert users?

If not, then this analysis does not apply. A different analysis that focuses only on implementers and expert users should be used.

But, do non-expert users need names?

Yes.

So, should other names be created for non-expert users? Would implementers and expert users need to also know the non-expert names? If so, what is lost if names that are prioritized for only non-experts are used to reduce the number of names? (I presume we should prioritize non-expert users).

It seems that implementers and non-experts generally need to know the details of algorithms regardless of the names chosen. If there are only ever certain parameters used with certain algorithms, perhaps they will be more readily memorized than if that isn't the case over time. Is this worth prioritizing over names that may be more useful to non-expert users or over reducing the number of names? Are there other things that are lost? What should our priorities be for naming here?

@dlongley I appreciate the thoughtful analysis above. I would personally answer the question of "What should a name communicate to a non-expert user?" differently. To me, it's not the name that communicates to the user that an expert has OK'd something for their application. Rather, it's an expert that has communicated the name to them for their application, and that name needs to be unique and memorable enough for them to find it in their library's code.

I also believe that optimizing the name for non-expert-users is a losing game, for this same reason.

Besides the points that have been already been raised, what happens if the date-strategy becomes widespread? Some are arguing it's a good idea, therefore we could potentially expect other specifications (outside HTTP signature) to use a similar concept. In HTTP signature we may have rsa-2005 as an alias for rsa-pss-sha512. Then later rsa-2026 is an alias for rsa-pss-sha3-512. Meanwhile, in an unrelated spec S1, rsa-2005 is an alias for rsa-v1_5-sha256 and in spec S2 rsa-2022 is an alias rsa-v1_5-sha512. It seems it would be error prone for implementers and experts to track the meaning of each of these aliases.

Meanwhile, in an unrelated spec S1, rsa-2005 is an alias for rsa-v1_5-sha256 and in spec S2 rsa-2022 is an alias rsa-v1_5-sha512.

There is an assumption here that the algorithm registry is maintained by experts that are aware of the other official IETF/W3C/etc registries and will ensure that conflicts like that don't occur. There are a number of potential ways things could go south that experts maintaining the registry would protect against.

To put it another way, what happens if any string conflicts with any other string? For example, "ed25519" is a good example -- today, there is only one set of parameters for it (which is a good thing)... so do we define it as "ed25519"? Or do we take an extra step to future proof? There was a time where "rsa" had fewer options than it does today... there is value in versioning and future proofing. The question in this thread is whether the current practice is useful to the degree that it could be.

Besides the points that have been already been raised, what happens if the date-strategy becomes widespread?

It is already a strategy that is gaining adoption, look at the registry on the left here:

https://w3c-ccg.github.io/ld-cryptosuite-registry/

and this registry:

https://ns.did.ai/

It's clear that the HTTP WG does not prefer the date format, and I'm going to stop pushing that in the group given the strong objections.

However, this issue isn't going away even if the HTTP WG keeps the current proposed text.

Perhaps people in the HTTP WG would be more amenable to versions instead of dates? After all, versioning is something that most developers across the entire spectrum of capability are used to dealing with.

Closing this issue as consensus seems clear to keep current naming practices for algorithm identifiers.

I disagree strongly with closing this issue for the following reasons -- there is no consensus yet:

1. It is not clear why https://www.iana.org/assignments/jose/jose.xhtml isn't being used for the algorithm names and that new values are being created just for the HTTP Signatures spec (since the values in the specification seem to be in the JOSE registry already).
2. It's not clear how the naming convention in the spec will be applied to EdDSA (parameter-less).
3. The versioned "name-version" proposal above might be something that would work for the HTTP WG and/or IETF CFRG and it has not been considered yet.
4. There was a request by the Chairs to check in with the IETF CFRG for feedback and I would expect that this issue would not be closed until we got that feedback.

If we have consensus, it's that the HTTP WG is concerned about date-based identifiers. I'm happy to step aside on that particular proposal.

The items above remain and the expectation was that they'd be discussed in this issue or I can open new issues for each item if that would be preferred.

I suggest that we let the chairs decide that. I do, however, think that the preponderance of opinion is overwhelmingly against @msporny's view. But the chairs are the final arbiters of that in our process. And the mailing list is the venue where that decision will be concluded.

I suggest that we let the chairs decide that.

Agree.

I do, however, think that the preponderance of opinion is overwhelmingly against @msporny's view.

There is no single "@msporny's view" :) -- note the concerns here: #1510 (comment)

As long as there are concrete responses to each of those that have Chair buy in, I'm fine.

But the chairs are the final arbiters of that in our process. And the mailing list is the venue where that decision will be concluded.

Yes, and my expectation was that the above would happen first, and then this issue would be closed.

FWIW, your list of concerns highlights a problem with this issue as opened: the issue asks for a change rather than describing a problem. A single proposed change can address multiple problems.

So on those grounds, it might be reasonable for Justin to close this as an editor and request that you open issues.

That all said, the extra concerns you raise do not suggest any need for any substantial change of direction. I might raise an issue for the thing John Mattson asked about RSA key sizes and maybe ask for NIH justification regarding JWA.

@msporny There was not consensus to make the change request.

1. JWA algorithms were discussed previously and the context for application of JWA algorithm selection and definition is a different context from what's being used here. Newly-defined JWA entries will not take this spec into consideration and therefore might not map appropriately, and we have no control over that. It's not desirable to require the registration of an algorithm in a JOSE-specific registry just to use it in a non-JOSE algorithm space. The guidelines for using JWA algorithms outside of JOSE, currently in the document, were written as a compromise. This provides a way to use JWS algorithms without explicitly using JWA identifiers, which is a pattern that can be used for other algorithm collections as well. Furthermore, JWA algorithms are also usually used with JWK's, which have their own "alg" field. If we replicated the "alg" field from JWA, we would need to reconcile those layers. The current approach in the document is equivalent to the hs2019 pseudo-algorithm that was defined in the initial draft, but without the need for the second layer fake identifier.
2. As requested previously, please propose text for use of EdDSA: Add Ed25519 support: algorithm definition and examples #1509 (this has also been asked on the list)
3. The "version" based identifiers suffer from all the same problems that the "year" based identifiers do that were discussed. The counter-proposal didn't add anything to the solution space. It wasn't just the "year" portion that was problematic, in other words, and that was clear to me.
4. To my memory, the request to CFRG was for algorithm review, including parameters used for each definition. The approach of using a single identifier for algorithms with fixed parameters was already discussed and got positive feedback.

The discussion on the list did not alter the sentiment from the meeting in the slightest, and so I closed the issue.