Considering adding constant for the PKIX Algorithm Identifier

[stormshield-gt]

When implementing a crypto provider only for signature, I'm obligated to add a direct dependency to webkpi in order to benefit from the constant of the webkpi::alg_id module . The rustls' verify example for provider does the same thing

It would be nice if pki-types do provide this constants because it will ensure we are using the version of webpki of whatever the rustls crate is using.

Basically, it would mean to migrate the webkpi::alg_id module here.
Are you open to that kind of changes?

[ctz]

I don't really object to this, though it will make adding algorithm support to webpki slightly more time-consuming.

But equally don't want anyone to think that somehow this somehow is a master list, or that they need to land a PR here to implement a different algorithm. You can do, eg, AlgorithmIdentifier::from_slice(&[0x06, 0x03, 0x2b, 0x65, 0x71]) in any crate. It would strictly be a convenience.

[cpu]

It sounds like with the right documentation reminding folks of the AlgorithmIdentifier::from_slice option we would be amenable to making this more convenient as requested.

@stormshield-gt I suspect the core maintainers won't have a chance to prioritize this work. Would you be interested in making the required PRs against this repo, webpki, and rustls? If you aren't that's OK but I will probably suggest closing this issue in that case.

[stormshield-gt]

I will be open to make the required PRs but I think I want to delay this until I submit my PR on rcgen that will need this. I feel bad adding this without also adding a PR that actually have a use case for it. We can close the issue for now if it helps the maintenance.

It sounds like with the right documentation reminding folks of the AlgorithmIdentifier::from_slice option we would be amenable to making this more convenient as requested.

The best API I can I think of would be a const function that could take a &[u64] to construct an AlgorithmIdentifier, because that's how OID appear in the RFCs. But I suppose this is not trivial because asn1_rs crate requires a macro for doing these kinds of things.