Hi Christian,
thanks for your feedback.
We are talking about a few values for hash algorithms and today most
implementations would probably just stick with SHA-256.
The hash algorithms are, of course, the well-known algorithms that
everyone implements in both of the registries. Both registries use
existing algorithms rather than inventing new algorithms (which is kind
of obvious). Hence, when it comes to actual implementations, the hash
algorithms are not impacted by the choice of the registry itself.
Also, it is necessary to keep both registries up-to-date since they are
both used.
Ciao
Hannes
Am 26.12.2023 um 00:02 schrieb Christian Amsüss:
Hello Hannes,
On Sat, Dec 23, 2023 at 08:15:14PM +0100, Hannes Tschofenig wrote:
2) Christian, you argued against the use of the IANA "Named Information
Hash Algorithm Registry" for the hash algorithms. The argument was that
the algorithm registry is not well maintained. You suggested to use the
COSE algorithms registry instead. This would turn the following URI from
urn:ietf:params:oauth:ckt:sha-256:SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w
to urn:ietf:params:oauth:ckt:-16:SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w
Maintaining a hash algorithm registry seems trivial since the number of
hash algorithms don't seem to grow quickly. Re-using the COSE algorithms
registry, however, might confuse readers since it contains a lot of
other algorithms.
I've primarily reiterated what came back to me last time I suggested
using the NIH registry where something was picking COSE algorithm
numbers over NIH numbers (that was for CBOR tags). I brought it up
because I do consider the points made back there valid: The COSE
registry for hashes has no arbitrary limits in the number of algorithms
it can support efficiently, contains algorithms not in the NIH registry,
and appears to be in more widespread use by systems that already use
CBOR. Implementations that use COSE as their primary view on
cryptography would need to carry around a second set of identifiers to
its algorithms.
To my limited understanding, the JWT equivalent in RFC9278 did not have
the luxury of having a registry for hashes in JOSE; in that light, it
makes sense to have reached out to the NIH algorithms, but it is my
impression that in COSE things are often done different with the benefit
of hindsight, enhancing concistency within the COSE ecossystem.
At any rate, this is not a document I'm too familiar with -- I merely
found the inconsistency and pointed it out from a recent similar
experience. If the group prefers to keep the NIH identifiers, that's
fine with me -- although if ever I come across the need to implement
this, chances are my implementations will use COSE algorithm
identifiers, and map those to the NIH entries. In that case it may also
make sense to point to such a mapping in the respective registries.
The point on identifiers being confusing given the mixed nature of the
COSE registry is a good and important one; in the spirit of fixing
things we find lacking, this might be the point where such a column is
added for easier use. (There is probably some history to why that was
not done in the first place somewhere in the COSE pool of experience).
Best regards
Christian
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
