👍

Working on an implementation of this for InspIRCd.

Should this describe the hash format somewhat, i.e. is it hexadecimal or base64, or does that not matter? I'm thinking about networks switching to a different webclient, or users using the same cert between web and direct connection.

(I'd prefer base64 personally, due to length, but I guess it has to be hex for compatibility with what ircds do themselves...)

Basically every IRCd uses hexadecimal with no separating : but it wouldn't hurt to define it yeah.

Any suggestions on how to specify the format? Perhaps a prefix to the fingerprint like "base64;" or "b64;" if not hex?

Perhaps it would be better to not include the algorithm in the option name, and instead create a separate IRCv3 specification documenting a format for cert fingerprints that includes the ability to include the hash algorithm and encoding in the format of the fingerprint itself.

Good idea.

I'm glad the hash algorithm is mentioned in the keyname (eg certfp-sha256). I mean, we use sha256 now, but that won't be forever. Similarly, there could be a transition point some day where we have both sha256 and Algorithm X in use for a few years, where both need to be communicated. Your spec allows all that. Great :)

I agree with @SadieCat to make certfp-sha256 use hexadecimals without using the colon sign. I think we can just define it as that and not allow different different encodings (eg base64) for certfp-sha256. No need to make the spec more complex in that respect.

As for whether to include the algorithms (and how they should be encoded) in the main specification itself or elsewhere. I don't mind either way. My gut feeling says a separate spec (or registry) sounds most logical, though. Avoids the clutter/talk about hash algorithms and encoding in the main WEBIRC spec.. and allows more room for examples and references on how to calculate them.

@jobe1986 have you got enough to go on in the comments here to make any of the modifications discussed?

I'm still not sure whether it should be certfp-<algo>=<fingerprint> or certfp-<algo>:<fingerprint>.

Personally I prefer in the key name to prevent duplicate keys with different values for situations where you may want to provide the fingerprint in more then one algorithm.

@SadieCat @syzop @grawity pls confirm you're happy to see this merged.

Looks good to me, although it might be better to be more explicit about algorithm names so that we don't end up with certfp-sha256 and certfp-SHA2-256.

I think it's better to keep the algorithm name as part of the key name. (Although it would also be possible to avoid the duplicate key problem using certfp=sha1:foo,sha256:bar,sha3:baz but that seems unnecessarily complex and possibly risky, since you'd have to parse the value, while certfp-sha1=foo certfp-sha256=bar achieves the same thing using existing code.)

certfp-sha256=abc sounds good.

I do have a comment on the latest edit. Hexadecimal for certfp is normal and we already concluded is used by pretty much all IRCds, so that is good. However, for spki fingerprint using base64 is normal, see RFC7469 and ctrl+f base64. I'm not aware of any implementation doing that hexadecimal. You can google and see the difference if you search on "spki fingerprint" "base64" versus "spki fingerprint "hexadecimal". The hits for both are low, but the base64 one has 10 times more hits than hexadecimal, and if you click on the hits for hexadecimal they are actually not about hexadecimal in the spkifp end result but about something else (unrelated).

Sorry for not mentioning that earlier, I only noticed it now that you put that text in.

I also agree with @grawity about this (which Jobe already raised as well):

it might be better to be more explicit about algorithm names so that we don't end up with certfp-sha256 and certfp-SHA2-256.

If not going with that registry, which I can totally understand too, then maybe just illustrate with the most common ones. So: sha1, sha256, and perhaps sha3-256. Almost everyone will use one (or more) of those hashes for the next few years.

I do have a comment on the latest edit. Hexadecimal for certfp is normal and we already concluded is used by pretty much all IRCds, so that is good. However, for spki fingerprint using base64 is normal, see RFC7469 and ctrl+f base64. I'm not aware of any implementation doing that hexadecimal. You can google and see the difference if you search on "spki fingerprint" "base64" versus "spki fingerprint "hexadecimal". The hits for both are low, but the base64 one has 10 times more hits than hexadecimal, and if you click on the hits for hexadecimal they are actually not about hexadecimal in the spkifp end result but about something else (unrelated).

Hmm to be honest I was kind of wishing that this would be just a transfer encoding, not something that gets directly exposed to users, and the ircd would internally keep and compare fingerprints as binary blobs instead of strings...

InspIRCd's SPKI implementation will use hex but as long as it's in a format we can convert from I'm not bothered if this uses hex or base64.

I do have a comment on the latest edit. Hexadecimal for certfp is normal and we already concluded is used by pretty much all IRCds, so that is good. However, for spki fingerprint using base64 is normal, see RFC7469 and ctrl+f base64. I'm not aware of any implementation doing that hexadecimal. You can google and see the difference if you search on "spki fingerprint" "base64" versus "spki fingerprint "hexadecimal". The hits for both are low, but the base64 one has 10 times more hits than hexadecimal, and if you click on the hits for hexadecimal they are actually not about hexadecimal in the spkifp end result but about something else (unrelated).

Hmm to be honest I was kind of wishing that this would be just a transfer encoding, not something that gets directly exposed to users, and the ircd would internally keep and compare fingerprints as binary blobs instead of strings...

Something like that was my thinking as the purpose of the WEBIRC command is to send technical information to the IRCd that the IRCd can then decide what it wants to do with. As for the Base64 SPKI thing, I have seen a solanum network using spki fingerprints encoded in hex.

There is no reason why an IRCd cannot decode the hex into a binary blob and then re-encode into base64 if it so wishes. In fact writing a simple routine to decode hex is far simpler then doing the same for base64. So in my mind this has always been about being a transfer encoding.

Ah okay, didn't know spki fp in hexadecimal notation existed. Then it doesn't matter, so yeah fine to use hexadecimal to keep both cert and spkifp consistent.

@jwheare Yup, I'm fine with merging

OK thanks, I can't work out if any more changes were requested re certfp-<algo>=<fingerprint> Sounds like the format has agreement but there was a call for more specific examples?

Hopefully that last commit should cover any remaining concerns, unless anyone has anything else to say about it.

LGTM, will allow for final comments and merge tomorrow.

This is now implemented in InspIRCd and is available on the testnet. We currently only have gateway configs for KiwiIRC.com enabled but if anyone else wants to add their gateway for testing then they can poke me in #inspircd.dev on ChatSpike and I can add it.