Hi list,
if I may ask: Are there any plans to eventually replace
proof@metacode.biz with something like proof@keyoxide.org?
When I first looked into Keyoxide I was pretty irritated by this
(wondering where metacode.biz comes from and a .biz domain gave me the
wrong impression). Now I have more context on this and it seems like
there are more pressing issues but IMO it would still make sense to
eventually replace the domain (hopefully it wouldn't require much more
effort than extending the code a bit to accept both the old and the new
notation and update the documentation to only refer to the new
notation).
Here are some advantages and drawbacks I could think of for switching to
proof@keyoxide.org:
- Advantages
- Less confusing. If a user enters keyoxide.org into their browser
they will immediately see what this is about (vs. visiting
https://metacode.biz/ which is about the company and has no
hyperlink to https://metacode.biz/openpgp/).
- metacode.biz sounds commercial (like e.g. Keybase) which is in
contrast to Keyoxide (decentralized, open source, privacy friendly,
transparent funding, etc.)
- Also .biz vs. .org
- https://metacode.biz/openpgp/proofs could become part of the Git
repository (https://codeberg.org/keyoxide/keyoxide-web/)
- Drawbacks
- Supporting and switching to a new signature notation requires
additional effort (software, tests, and documentation).
- If this notation is supposed to be supported by other
clients/software as well than keyoxide.org might still not be
generic enough (although it seems still better than metacode.biz and
using something like openpgp.org might not be possible).
- Things to consider
- When waiting for too long it will likely become only more difficult
- If there is a chance that breaking changes to the notation could be
required in the future it might make sense to version it (e.g.
proof-v1@keyoxide.org).
If this is something to seriously consider it probably makes sense to
track this on https://codeberg.org/keyoxide/ as well (if so would the
doipjs repository be the most appropriate?).
Anyway, I just wanted to bring this up because I'm not too enthusiastic
about adding a proof@metacode.biz signature notation to my OpenPGP key
(most people likely wouldn't even notice such notations but for some it
might be strange and confusing) and because I didn't find any prior
discussion about this.
Kind regards,
Michael
PS: I'll drop some links here for some additional context from my brief
research into this:
- https://tools.ietf.org/html/rfc4880#section-5.2.3.16
- OpenPGP Message Format RFC: Notation Data
- "Names in the user namespace consist of a UTF-8 string tag followed
by "@" followed by a DNS domain name. Note that the tag MUST NOT
contain an "@" character. For example, the "sample" tag used by
Example Corporation could be "sample@example.com"."
- "Names in a user space are owned and controlled by the owners of
that domain. Obviously, it's bad form to create a new name in a DNS
space that you don't own."
- "Since the user namespace is in the form of an email address,
implementers MAY wish to arrange for that address to reach a person
who can be consulted about the use of the named tag. Note that due
to UTF-8 encoding, not all valid user space name tags are valid
email addresses."
- https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6
- IANA: Signature Notation Data Subpacket Types
- https://keyoxide.org/guides/openpgp-proofs
- "@metacode.biz is the domain of the person who came up with OpenPGP
proofs and serves as a namespace for the notation."
- This isn't mentioned on the "About" and "FAQ" pages.
- https://mailarchive.ietf.org/arch/msg/openpgp/Dtl5aVds3ZmVkAjQfWvlzgJhlt4/
- [openpgp] Registration of the 'proof' notation
- Contains all the other relevant links
- https://github.com/wiktor-k/openpgp-proofs#for-users
- The proof@metacode.biz notation existed before it became Keyoxide
Hi Michael,
I've designed the original `proof@metacode.biz` notation.
I see you've pieced the history nicely together. Just for posterity's
sake I also had a different design using User IDs:
https://github.com/wiktor-k/distributed-ids
And to be completely transparent I based my design on Linked Identities
that OpenKeychain once had:
https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
Sadly it was removed because no-one used it:
https://github.com/open-keychain/open-keychain/pull/2408
As for the notation key: sorry for the inconvenience! Keyoxide uses that
for backwards-compatibility reasons.
The story goes like this: the original used my domain name because
that's what RFC 4880 requires for non-standardized notations. Then
Keyoxide begun to use it, and keys.openpgp.org also had profiles at some
point: https://gitlab.com/hagrid-keyserver/hagrid/-/merge_requests/172
The domain part was always problematic, everyone wanted their own domain
in there (gee, I really need to update the homepage :-/ ) 🤷 and I
thought it would be better to get the name in IANA
namespace. Unfortunately it didn't go well, it seems my proposal lacked
a couple of people that'd express they would want the `proof` notation
in the spec and so that just didn't happen.
Using standardized notation would also mean users would have to pass
`--expert` flag to GnuPG when adding notation (minor
inconvenience). Seeing you're not the first (and last) person that
doesn't like my domain name I guess the migration to @keyoxide.org is
imminent. (Well, people think of these proofs as "keyoxide proofs" now
anyway).
For the record the notation key is completely irrelevant for
the proof checking and Keyoxide could migrate to proof@keyoxide.org
right now and still support the old proof@metacode.biz ones just fine.
Hope this clears some matters up.
Sorry for the confusion again! It was fun while it lasted :)
Kind regards,
Wiktor
On Thu, 06 May, 2021 at 09:11:41 +0200, Wiktor Kwapisiewicz wrote:
> I've designed the original `proof@metacode.biz` notation.
Thanks for designing all of this btw! :)
> The domain part was always problematic, everyone wanted their own domain> in there (gee, I really need to update the homepage :-/ ) 🤷
I wasn't aware of that part (everyone wanting their own domain).
I'm also not sure how this went from
https://github.com/wiktor-k/openpgp-proofs to Keyoxide (if Keyoxide is
considered the official successor or if it's more like an "alternative"
implementation based on your design/notation).
I thought Keyoxide was the successor but looking at the Git contributors
via the web UI it seems more like a new/alternative implementation by
Yarmo Mackenbach. Not sure how much the two of you work together.
> I thought it would be better to get the name in IANA> namespace. Unfortunately it didn't go well, it seems my proposal lacked> a couple of people that'd express they would want the `proof` notation> in the spec and so that just didn't happen.
Yeah, unfortunately the standardization around OpenPGP seems really
slow/unfocused, at least from my outside perspective (I'm waiting for
rfc4880bis for years now while RFC 4880 is seriously outdated by now).
Anyway, I'm also a bit puzzled why they're not making use of the IETF
namespace. There are still "No registrations at this time.":
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6
AFAIK it wouldn't have to be part of the OpenPGP RFC and since "Notation
names are arbitrary strings encoded in UTF-8." there isn't even a
limited amount of code points. So it could make sense to let reasonable
Internet-Drafts make use of them.
Seems like they've intended to add "Note: Experts are to verify that the
proposed registration is necessary and *SHOULD* provide general benefits
for the wider OpenPGP community." via
https://tools.ietf.org/html/draft-openpgp-iana-registry-updates-02#section-5.6
but that also never went through...
> Using standardized notation would also mean users would have to pass> `--expert` flag to GnuPG when adding notation (minor> inconvenience).
Oh, that seems strange... I wasn't aware of that.
> Seeing you're not the first (and last) person that> doesn't like my domain name I guess the migration to @keyoxide.org is> imminent. (Well, people think of these proofs as "keyoxide proofs" now> anyway).
Btw it isn't that I don't like your domain name (for a company
metacode.biz is really cool) I just feel like it isn't that appropriate
for an open standard (and not just because of the name but also because
the main content doesn't refer to the standard). Just so that this
doesn't come off the wrong way (didn't seem that way but just in case).
It also wouldn't have to end with @keyoxide.org (I'm still not sure how
focused this currently is on Keyoxide). It could also be something like
v1@openpgp-proofs.$gTLD (I'm just not familiar enough with everything to
come up with good names). Or one could even use something like
openpgp-proof@... where the domain doesn't matter (i.e. each Software
could use their own domain) and Implementations only match against the
part left of @ but that seems like a (really) bad idea.
Something like keytoidentity.foundation might also be suitable.
> Hope this clears some matters up.
It does, thanks a lot!
> Sorry for the confusion again! It was fun while it lasted :)
No problem, I get it :)
Kind regards,
Michael
Hi Michael,
> Thanks for designing all of this btw! :)
Haha, no problem! Actually I'd pass all credit to Vincent Breitmoser (of
OpenKeychain) for the design of Linked Identities [0]. I just took his
idea and made it easier for the users :)
[0]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01> I wasn't aware of that part (everyone wanting their own domain).> I'm also not sure how this went from> https://github.com/wiktor-k/openpgp-proofs to Keyoxide (if Keyoxide is> considered the official successor or if it's more like an "alternative"> implementation based on your design/notation).>> I thought Keyoxide was the successor but looking at the Git contributors> via the web UI it seems more like a new/alternative implementation by> Yarmo Mackenbach. Not sure how much the two of you work together.
Well that's right what you wrote. I worked on Proofs around 2019,
created a library and a demo page [1]. Then I published that on Mastodon
and got some early feedback most notably from Amolith [2] and Alex [3]
but it didn't get a widespread adoption I had hoped it would.
[1]:
https://metacode.biz/openpgp/key#7F9116FEA90A5983936C7CFAA027DB2F3E1E118A
[2]: https://nixnet.social/users/amolith
[3]: https://alexschroeder.ch/wiki/2020-05-08_Replacing_Keybase
Then apparently from no-where Yarmo created alternative implementation
based on the same idea (darn, why did I put so much time in writing a
library?! ;)). The design was intentionally super-simple so just looking
at these proof URLs and re-implementing it was not that complex.
Somewhere back then we got in touch and stay in touch ever since
discussing some feature design issues at length. I'm happy that Yarmo
still listens to me after all these years even when I'm not actively
developing any Proof code and he gets the rubber duck debugging [4] from
it so I guess it works really fine that way :)
[4]: https://en.wikipedia.org/wiki/Rubber_duck_debugging> Yeah, unfortunately the standardization around OpenPGP seems really> slow/unfocused, at least from my outside perspective (I'm waiting for> rfc4880bis for years now while RFC 4880 is seriously outdated by now).>> Anyway, I'm also a bit puzzled why they're not making use of the IETF> namespace. There are still "No registrations at this time.":> https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6>> AFAIK it wouldn't have to be part of the OpenPGP RFC and since "Notation> names are arbitrary strings encoded in UTF-8." there isn't even a> limited amount of code points. So it could make sense to let reasonable> Internet-Drafts make use of them.>> Seems like they've intended to add "Note: Experts are to verify that the> proposed registration is necessary and *SHOULD* provide general benefits> for the wider OpenPGP community." via> https://tools.ietf.org/html/draft-openpgp-iana-registry-updates-02#section-5.6> but that also never went through...
Yeah. For the record I'm working on Sequoia PGP and coincidentally I'm
observing OpenPGP ML closely. It seems there is a push to change the
registers from EXPERT REVIEW to SPECIFICATION REQUIRED that'd allow just
writing a spec and thus "squating" a name. Actually this is already a
common practice when GnuPG is inventing their own things that are in
IETF namespace and then "de facto" standardizing it.
>> Using standardized notation would also mean users would have to pass>> `--expert` flag to GnuPG when adding notation (minor>> inconvenience).>> Oh, that seems strange... I wasn't aware of that.
I just remembered I added a FAQ section about the notation name back in
2019:
https://github.com/wiktor-k/openpgp-proofs#faq
The question now is basically the practical aspect: would --expert scare
people off and raise questions? (just like `@metacode.biz` did?).
There is also another dimention: GnuPG is currently the only client that
can add proofs but it's perfectly possible to write a special Keyoxide
client that will have a better UI (e.g. validating the proof before
adding it to key or something like that).
I recommend Sequoia PGP obviously, haha. Just check out this
coincidental example:
https://docs.sequoia-pgp.org/sequoia_openpgp/packet/signature/struct.SignatureBuilder.html#method.add_notation> Btw it isn't that I don't like your domain name (for a company> metacode.biz is really cool) I just feel like it isn't that appropriate> for an open standard (and not just because of the name but also because> the main content doesn't refer to the standard). Just so that this> doesn't come off the wrong way (didn't seem that way but just in case).>> It also wouldn't have to end with @keyoxide.org (I'm still not sure how> focused this currently is on Keyoxide). It could also be something like> v1@openpgp-proofs.$gTLD (I'm just not familiar enough with everything to> come up with good names). Or one could even use something like> openpgp-proof@... where the domain doesn't matter (i.e. each Software> could use their own domain) and Implementations only match against the> part left of @ but that seems like a (really) bad idea.>> Something like keytoidentity.foundation might also be suitable.
Ha, yes, interestingly using `proof@` prefix was being considered :)
(Also `proof@keys.openpgp.org` key that was used back when
keys.openpgp.org had mini-keyoxide built-in)
The idea about @domain suffix though is that it's obvious who is
controlling the semantics of the notation value. For example today it's
Yarmo that decides that Gitea proofs look like this but GitHub proofs
look like that. For the record I like the recommendation of RFC that
says one should create a valid mail inbox with the same address as the
notation, just in case someone had questions about semantics.
The number of proofs is increasing fast and creating Internet-Drafts for
all of them could be a burden. Still, I think it would be a nice idea if
all proofs had written documents describing the verification process not
only de facto implementation.
(I started writing something like that with proof verification logic
back then:
https://github.com/wiktor-k/openpgp-proofs/blob/master/proofs.json#L14-L39 ).
> It does, thanks a lot!
Glad I could help and shed some light on this matter, maybe there really
should be a History section on Keyoxide haha. It's just no-one was
interested in this topic previously. Adding proofs to keys was enough :)
See you later!
Kind regards,
Wiktor
Hi Wiktor,
> Somewhere back then we got in touch and stay in touch ever since> discussing some feature design issues at length. I'm happy that Yarmo> still listens to me after all these years even when I'm not actively> developing any Proof code and he gets the rubber duck debugging [4] from> it so I guess it works really fine that way :)
Couldn't have done it without the rubber ducking!
> The question now is basically the practical aspect: would --expert scare> people off and raise questions? (just like `@metacode.biz` did?).
I think I'd still rather avoid --expert and use the @domain syntax to
give new people a pointer to what on Earth could possible be those pesky
proofs that keep popping up everywhere in keys? (wishful thinking here)
>> It also wouldn't have to end with @keyoxide.org (I'm still not sure how>> focused this currently is on Keyoxide). It could also be something like>> v1@openpgp-proofs.$gTLD (I'm just not familiar enough with everything to>> come up with good names). Or one could even use something like>> openpgp-proof@... where the domain doesn't matter (i.e. each Software>> could use their own domain) and Implementations only match against the>> part left of @ but that seems like a (really) bad idea.> > The idea about @domain suffix though is that it's obvious who is> controlling the semantics of the notation value. For example today it's> Yarmo that decides that Gitea proofs look like this but GitHub proofs> look like that. For the record I like the recommendation of RFC that> says one should create a valid mail inbox with the same address as the> notation, just in case someone had questions about semantics.
I hadn't considered that but in my mind, keeping the proofs@domain away
from keyoxide.org makes a lot of sense, it follows my pattern of
frantically keeping the name Keyoxide out of everything that could
potentially be used by other implementations and clients. The concept of
openpgp-based proofs is larger than Keyoxide, it might even be larger
than the doip library when viewed as just an implementation of that
protocol.
So, whose responsibility does defining the proofs become? A working
group? Something simpler? More complex?
Keeping in mind that that entity will also need to draft (in the near
future) a protocol that would allow any service provider to implement
openpgp proofs. All this manual work of defining each proof is ideally
transitory.
Kind regards,
Yarmo
Michael,
Not sure if you're still following Keyoxide but I think you'd be glad to
hear that "metacode.biz" is no more!
The Keyoxide people launched a new project for working on the "spec"
side of proofs: https://ariadne.id/ (the "Keyoxide" name refers to the
frontend mostly now, as far as I understand).
You can see their announcement post here:
https://blog.keyoxide.org/ariadne-spec/
Aaaand... I guess that's it... have a nice day! 👋
Kind regards,
Wiktor