Linked cryptographic identities

[franzaps]

Rendered

[vitorpamplona]

Nice! Is it necessary to index the <type>:<fingerprint>? Do we expect people to query by it?

[franzaps]

@vitorpamplona Thanks and yes, absolutely. This way coming across any PGP key or certificate in the wild one can check if that identity is also on nostr.

In my particular case for zap.store, it's one of the ways to link APKs with developers on nostr.

@fiatjaf this is my second attempt after failure with NIP-39, what do you think?

[dskvr]

Looks good. Seems like this could also link other nostr pubkeys, I could use this now.

Is it necessary to index the <type>:<fingerprint>

Necessary for my use case as well.

[dskvr]

Should keys be enumerated? As drafted, this NIP can work for any key that can produce a signature.

[franzaps]

Not listing them would lead to undesired inconsistencies (example, someone prefixes the i tag with gpg: instead of pgp:).

We can add a nostr type but there again it's important to define the exact format of the event to be signed.

[dskvr]

Why would it be a problem if a client prefixed the i tag with gpg for a gpg signature?

[franzaps]

So clients can easily find these events?

In my particular case I am indexing all sorts of release artifacts (APKs, DMGs, AppImages, etc) some signed with certificates and others with PGP. Given an artifact, I want to be able to quickly look up if its signer also controls a nostr key. If we use pgp or gpg interchangeably now clients have to make two different requests. Don't you think it makes sense?

Of course this is nostr and people can ultimately publish whatever they want

[dskvr]

Not necessarily. You: "I support PGP proof", Them: "I have GPG proof", You: "..."

If we use pgp or gpg interchangeably now clients have to make two different requests.

While this may be superfluous since your case seems to flag encryption support, if you wanted to be extra safe you could do { "#i": ['pgp:<key>', 'gpg:<key>']} ... 'pgp:<key>' or 'gpg:<key>' in a single REQ.

Of course this is nostr and people can ultimately publish whatever they want

And it is because of this I questioned the need foor enumeration, or otherwise, enumeration of a tiny subset of available cryptographic proofs

[franzaps]

I think it's good to have some basic agreement on these labels! I will change it to "recommended" types so it's just that, a recommendation, and let's add a nostr one.

[Semisol]

do we not already have linked identities? it can support pgp and x509, the last implementation was removed because it signed a string that didn't depend on the npub

[franzaps]

@Semisol if you confirm it will get merged I can make a PR to NIP-39

[franzaps]

@staab @fiatjaf @vitorpamplona This one is good to merge. I'm happy to create a PR on NIP-39 if I get a confirmation that it will actually get merged.

[staab]

It seems like this does the same thing as NIP 39? I like the dedicated event as an addition, but I would add it as an addition to NIP 39, unless I'm misunderstanding its purpose. Is this implemented anywhere?

[franzaps]

It seems like this does the same thing as NIP 39? I like the dedicated event as an addition, but I would add it as an addition to NIP 39, unless I'm misunderstanding its purpose. Is this implemented anywhere?

It used to be in NIP-39, but was flawed, and semisol silently removed it instead of asking for a fix. This is a new proposal. I'm fine with either kind 10069 or kind 0. I can create a PR to NIP-39 but I first wanted to make sure it will be merged.

Yes it's being implemented! Developers on zap.store will start using this very soon. I started producing these events but only on relay.zap.store.

[caesar]

I'd love to see a standardised way to claim an OpenPGP identity in Nostr, but I have a few thoughts:

• I think it would make more sense to add these identities to NIP-39 instead of adding another message type; I don't understand the benefit to there being a new message type which almost duplicates NIP-39's functionality.

• I think the verbiage of the English-language message to be signed is unnecessarily verbose. It would probably make sense for the sake of consistency to use the same proof string used by NIP-39: Verifying that I control the following Nostr public key: "<npub encoded public key>"

• I think it would probably make sense to use the prefix openpgp4fpr, which is a standard. Note that PGP and GPG are the names of software, the encryption standard they implement is called OpenPGP.

[franzaps]

@caesar Yes this will be added to NIP-39. I don't mind updating the spec to what you suggest.

[franzaps]

Closing in favor of #1335