10
45
Fork
You've already forked doipjs
28

Add support for Direct Key Signature proofs #173

Open
wiktor wants to merge 3 commits from wiktor/doipjs:wiktor/add-support-for-dks into dev
pull from: wiktor/doipjs:wiktor/add-support-for-dks
merge into: keyoxide:dev
keyoxide:main
keyoxide:dev
keyoxide:fix-irc-fetcher
keyoxide:new-claim-eveonline-143
keyoxide:prepare-new-release
keyoxide:fix-jsdoc-types
keyoxide:yarn-to-npm
keyoxide:support-openpgp-aspe-claims
keyoxide:support-html-alias
keyoxide:improve-activitypub-support
keyoxide:v1-restructure
keyoxide:into-es-module
keyoxide:support-aspe
keyoxide:fix-js-lsp-issues
keyoxide:improve-linting
keyoxide:add-markers
keyoxide:support-opencollective-claim
keyoxide:support-entity-decoding
keyoxide:use-rome-tools
keyoxide:support-cloudflare-buster
keyoxide:support-fediverse-posts
keyoxide:matrix-room-verification
Member
Copy link

Hi folks 👋

keys.openpgp.org merged Direct Key Signature support recently: https://gitlab.com/keys.openpgp.org/hagrid/-/merge_requests/219 and it seems it will be live on the production site any minute now

This PR amends the proof engine to look in direct key signatures, too.

What does it give in practice? ASPE-like proofs based on OpenPGP.

E-mails don't need to be verified or even published to use this. Just create a new User ID-less key, add a bunch of notations, upload to keys.openpgp.org and it should work.

For testing, this can be used: https://codeberg.org/wiktor/dks/src/branch/main/src/main.rs but if all pieces will be in place I'm thinking of creating a simple CLI interface to manage proofs in OpenPGP format.

I've added tests here but if someone can help deploying this thing somewhere I'd be really glad since then we could test that with keys.openpgp.org (when they're operational).

Key I've used for tests: https://testing.keys.openpgp.org/search?q=0x39D43B0401E47044066C6A2F425E832B36570E72

See you!

Hi folks 👋 keys.openpgp.org merged Direct Key Signature support recently: https://gitlab.com/keys.openpgp.org/hagrid/-/merge_requests/219 and it seems it will be live on the production site *any minute now* This PR amends the proof engine to look in direct key signatures, too. What does it give in practice? ASPE-like proofs based on OpenPGP. E-mails don't need to be verified or even published to use this. Just create a new User ID-less key, add a bunch of notations, upload to keys.openpgp.org and it should work. For testing, this can be used: https://codeberg.org/wiktor/dks/src/branch/main/src/main.rs but if all pieces will be in place I'm thinking of creating a simple CLI interface to manage proofs in OpenPGP format. I've added tests here but if someone can help deploying this thing somewhere I'd be really glad since then we could test that with keys.openpgp.org (when they're operational). Key I've used for tests: https://testing.keys.openpgp.org/search?q=0x39D43B0401E47044066C6A2F425E832B36570E72 See you!
Signed-off-by: Wiktor Kwapisiewicz <wiktor@metacode.biz>

Every time @wiktor shows up he brings in something really exciting!

What does it give in practice? ASPE-like proofs based on OpenPGP.

E-mails don't need to be verified or even published to use this. Just create a new User ID-less key, add a bunch of notations, upload to keys.openpgp.org and it should work.

In other words one could create UID-less self-signed P-256 or Ed25519 PGP (削除) key (削除ここまで) cert, fill it with notations and use (Hagrid) PGP keyserver almost like ASPE server, this is just fantastic! 💯 Basically this is a direct analogue of self-signed JWTs aka ASPs in the PGP world.

For testing, this can be used: https://codeberg.org/wiktor/dks/src/branch/main/src/main.rs but if all pieces will be in place I'm thinking of creating a simple CLI interface to manage proofs in OpenPGP format.

It definitely warrants some user-friendly tooling to be created to streamline the workflow 👍

I simply can't emphasize enough how big game changer this is for PGP side of Keyoxide and how eager I'm to see this merged and advertised through our docs! Many thanks for taking the initiative!

On personal note: this made my day!

Every time @wiktor shows up he brings in something really exciting! > What does it give in practice? ASPE-like proofs based on OpenPGP. > > E-mails don't need to be verified or even published to use this. Just create a new User ID-less key, add a bunch of notations, upload to keys.openpgp.org and it should work. In other words one could create _UID-less_ self-signed P-256 or Ed25519 PGP ~key~ cert, fill it with notations and use (Hagrid) PGP keyserver almost like ASPE server, this is just fantastic! 💯 Basically this is a direct analogue of self-signed JWTs aka ASPs in the PGP world. > For testing, this can be used: https://codeberg.org/wiktor/dks/src/branch/main/src/main.rs but if all pieces will be in place I'm thinking of creating a simple CLI interface to manage proofs in OpenPGP format. It definitely warrants some user-friendly tooling to be created to streamline the workflow 👍 I simply can't emphasize enough how big game changer this is for PGP side of Keyoxide and how eager I'm to see this merged and advertised through our docs! Many thanks for taking the initiative! On personal note: this made my day!
vladimyr left a comment
Copy link

In general this LGTM but I've been left wondering should we be more cautious to not alter doip's current behavior with regards to exception bubbing/throwing (more details in attached comment).

In general this LGTM but I've been left wondering should we be more cautious to not alter doip's current behavior with regards to exception bubbing/throwing (more details in attached comment).
src/openpgp.js Outdated
@ -293,0 +295,4 @@
const primaryUser = await publicKey.getPrimaryUser()
profile.primaryPersonaIndex = primaryUser.index
} catch (e) {
// there is no primary user but the key may have direct key signatures
Member
Copy link

Strictly speaking there are 3 cases in which key#getPrimaryUser throws:

  1. There really aren't any users meaning that there is no primary user:
// from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L469
throw exception || new Error('Could not find primary user');
  1. All users have invalid signatures meaning that there is no valid primary user:
// from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L469
// `exception` holds last signature validation exception
throw exception || new Error('Could not find primary user');
  1. There is a primary user but it is revoked:
// from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L482
throw new Error('Primary user is revoked');

Problem is that before, without direct key signature support and this newly added try-catch block, exception would simply bubble up. Now you caught it and proceeded to check for direct key signatures. Suppose there aren't any (publicKey.directSignatures.length === 0) should we store previously caught exception and rethrow it? Maybe this catch block should read something like:

} catch (e) {
 if (!hasDirectSignatures(publicKey)) {
 throw e
 }
 // proceed to find last signature with appropriate notation
}

What do you think?

Strictly speaking there are 3 cases in which [`key#getPrimaryUser`](https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L444) throws: 1. There really aren't any users meaning that **there is no primary user**: ```js // from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L469 throw exception || new Error('Could not find primary user'); ``` 2. All users have invalid signatures meaning that **there is no valid primary user**: ```js // from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L469 // `exception` holds last signature validation exception throw exception || new Error('Could not find primary user'); ``` 3. **There is a primary user but it is revoked**: ```js // from: https://github.com/openpgpjs/openpgpjs/blob/v5/src/key/key.js#L482 throw new Error('Primary user is revoked'); ``` Problem is that before, without direct key signature support and this newly added try-catch block, exception would simply bubble up. Now you caught it and proceeded to check for direct key signatures. Suppose there aren't any (`publicKey.directSignatures.length === 0`) should we store previously caught exception and rethrow it? Maybe this catch block should read something like: ```js } catch (e) { if (!hasDirectSignatures(publicKey)) { throw e } // proceed to find last signature with appropriate notation } ``` What do you think?
Author
Member
Copy link

What do you think?

Yep, excellent idea. I've extended the code with similar checks that are in other places (which seem kind-of redundant but I wanted to be consistent...? 😬).

I've also updated docs as there was an eslint warning that I overlooked.

> What do you think? Yep, excellent idea. I've extended the code with similar checks that are in other places (which seem kind-of redundant but I wanted to be consistent...? 😬). I've also updated docs as there was an eslint warning that I overlooked.
Author
Member
Copy link

@vladimyr wrote in #173 (comment):

Every time @wiktor shows up he brings in something really exciting!

Lol, I thought you were a goner and you're back with something like this... 🥹

Basically this is a direct analogue of self-signed JWTs aka ASPs in the PGP world.

Exactly. There are just minor differences: ASPs include domain names, so you can self-host (currently the keyserver is hardcoded in PGP proofs) and... no support for avatars in ASPs and these direct proofs (avatars were always using gravatar/libreavatar)... adding another notation like avatar@ariadne.id is simple (same for ASP) but I didn't want to bloat this PR too much.

It definitely warrants some user-friendly tooling to be created to streamline the workflow 👍

Oh yeah, I'm planning to create two: one command-line for paranoid folks and one web site with client side crypto for folks who want to just have it done. Not on the level of https://asp.keyoxide.org/ polish, just an example.

I simply can't emphasize enough how big game changer this is for PGP side of Keyoxide and how eager I'm to see this merged and advertised through our docs! Many thanks for taking the initiative!

Yeah, it's been long on my plate, but there are many moving parts. I think the deployment on keyoxide.org may be the hardest one 😬 but I think a side deployment by @Ryuno-Ki or someone else would be a great way to test this "in the wild".

On personal note: this made my day!

I've got a small list of these to keep you engaged every year... 😉 seriously - I'm happy that we're sharing the same enthusiasm for this feature... it feels like a natural improvement for the project IMO.

In general this LGTM but I've been left wondering should we be more cautious to not alter doip's current behavior with regards to exception bubbing/throwing (more details in attached comment).

Yes, let's keep the existing behavior as-is in all old cases. I'll need to cook a key for tests but I agree with your remarks. Many thanks 🙇

@vladimyr wrote in https://codeberg.org/keyoxide/doipjs/pulls/173#issuecomment-6109762: > Every time @wiktor shows up he brings in something really exciting! Lol, I thought you were a goner and you're back with something like this... 🥹 > Basically this is a direct analogue of self-signed JWTs aka ASPs in the PGP world. Exactly. There are just minor differences: ASPs include domain names, so you can self-host (currently the keyserver is hardcoded in PGP proofs) and... no support for avatars in ASPs and these direct proofs (avatars were always using gravatar/libreavatar)... adding another notation like `avatar@ariadne.id` is simple ([same for ASP](https://codeberg.org/keyoxide/doipjs/pulls/128)) but I didn't want to bloat this PR too much. > It definitely warrants some user-friendly tooling to be created to streamline the workflow 👍 Oh yeah, I'm planning to create two: one command-line for paranoid folks and one web site with client side crypto for folks who want to just have it done. Not on the level of https://asp.keyoxide.org/ polish, just an example. > I simply can't emphasize enough how big game changer this is for PGP side of Keyoxide and how eager I'm to see this merged and advertised through our docs! Many thanks for taking the initiative! Yeah, it's been long on my plate, but there are many moving parts. I think the deployment on keyoxide.org may be the hardest one 😬 but I think a side deployment by @Ryuno-Ki or someone else would be a great way to test this "in the wild". > On personal note: this made my day! I've got a small list of these to keep you engaged every year... 😉 seriously - I'm happy that we're sharing the same enthusiasm for this feature... it feels like a natural improvement for the project IMO. > In general this LGTM but I've been left wondering should we be more cautious to not alter doip's current behavior with regards to exception bubbing/throwing (more details in attached comment). Yes, let's keep the existing behavior as-is in all old cases. I'll need to cook a key for tests but I agree with your remarks. Many thanks 🙇
Signed-off-by: Wiktor Kwapisiewicz <wiktor@metacode.biz>
Signed-off-by: Wiktor Kwapisiewicz <wiktor@metacode.biz>
Author
Member
Copy link

@Ryuno-Ki would you mind taking a look at this PR? I'd really want to see it live somewhere so that I could work on the CLI proof updater part... kthxbai 🙇

@Ryuno-Ki would you mind taking a look at this PR? I'd really want to see it live *somewhere* so that I could work on the CLI proof updater part... kthxbai 🙇
First-time contributor
Copy link

My wish to keep my e-mail address confidential outweights everything.

That's why I created another OpenPGP keypair with an unusable e-mail address (https://keyoxide.org/noreply.keyoxide@duxsco.de). I could keep my real e-mail address confidential with https://keyoxide.org/<fingerprint>, though, but this would force me to use https://keys.openpgp.org which is a centralised service that - as it currently stands - would compete with my WKD setup.

But with this PR, things change. It allows me to hide my e-mail address with https://keyoxide.org/<fingerprint>, while https://keys.openpgp.org not competing with WKD. And, that's something I am more than fine with 🙂

My wish to keep my e-mail address confidential outweights everything. That's why I created another OpenPGP keypair with an unusable e-mail address (https://keyoxide.org/noreply.keyoxide@duxsco.de). I could keep my real e-mail address confidential with `https://keyoxide.org/<fingerprint>`, though, but this would force me to use https://keys.openpgp.org which is a centralised service that - as it currently stands - would compete with my WKD setup. But with this PR, things change. It allows me to hide my e-mail address with `https://keyoxide.org/<fingerprint>`, while https://keys.openpgp.org not competing with WKD. And, that's something I am more than fine with 🙂
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u wiktor/add-support-for-dks:wiktor-wiktor/add-support-for-dks
git switch wiktor-wiktor/add-support-for-dks
Sign in to join this conversation.
No reviewers
Labels
Clear labels
bug
Something is not working

Archived

enhancement
New feature

Archived

Contribution welcome
Get started contributing here
Good first issue
Good if you are new to the project or to open source contributions
Impact
External
 Affects the people using the project
Impact
Internal
 Affects on the people working on the project
Priority
Critical
 Work on right now
Priority
High
 Work on at earliest convenience
Priority
Low
 Work on in spare time
Priority
Medium
 Work on regularly
Review
Duplicate
 Already exists
Review
Off Topic
 Does not fall within the scope of the repo/project
Status
Backlog
 Is not being worked on yet
Status
Blocked
 Is waiting on something or someone
Status
Completed
 Is done
Status
In Progress
 Is being worked on
Status
Investigating
 Is waiting on research or questions
Status
Needs Decision
 Is waiting on a decision by the devs/contributors
Status
Needs Info
 Is waiting on additional information before it can be solved
Status
Needs Triage
 Is new issue that needs reviewing
Status
Testing
 Is being checked and verified
Status
Waiting For Review
 Is waiting on reviewers to approve
Status
Won't Fix
 Won't be fixed
Type
Bug
 Related to something not working as intended
Type
CI
 Related to continuous integration
Type
Documentation
 Related to documentation
Type
Enhancement
 Related to a new feature or an improved one
Type
New Claim
 Related to a new identity claim/proof
Type
Security
 Related to security
Type
Tests
 Related to code tests
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
keyoxide/doipjs!173
Reference in a new issue
keyoxide/doipjs
No description provided.
Delete branch "wiktor/doipjs:wiktor/add-support-for-dks"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?