phish108 / node-jose-tools Goto Github PK

It would be nice to have an introspection tool that reads a JWT and prints the type and basic header information.

in addition to the *key tools, a more mnemonic version of the tools would be nice, so one can call

jose key new -u sig -R -s 2048
jose key add -j keystore
jose key ls -j keystore 
jose key rm -j keystore 
jose key find -j keystore some_kid
jose key export -j keystore --format pem
jose key publish -j keystore

This requires the sanitizer to check more than one arguments.

Maybe it even makes sense to split the tools as such:

Hi,

Running on MacOS with node v13.8.0 and the latest node-jose-tools, and I get the error "unknown tool name" whenever I run any command.

Setup

I installed it as per the docs:

npm install -g node-jose-tools

Steps to reproduce

The simplest demonstration is this:

jose encrypt

it returns:

unknown tool name

Expected result

As a globally installed node module, I expect to be able to run jose from any working directory.

Workaround

Rather than run the documented jose command, it instead can run as follows:

cd /usr/local/lib/node_modules/node-jose-tools
node index.js encrypt ...

Analysis

Digging into the code, I see that sanitize.js looks for the file .lib/${toolname}.js.

I think the use of . is the root cause. I put console.log(fs.realpathSync('.')) into sanitize.js to debug what . is, and I get the current PWD of my shell, and not the root of the project as it expects.

in newkey line 35 the key type is set to RSA instead of EC. The tests should fail, but pass.

• If jose is called without any tool, then the available tools should be listed.

• If jose --help is called, then a basic usage and the tools should be presented.

The mock stdin tests randomly fail with timeout errors on macos.

Use #patch instead

The tool tries to load support functions from a non existent helpers folder instead from helper.

provide inline help directly from the CLI

Use two values hold and release.

• hold if only files in .github have changed
• hold if only files in tests have changed
• check if only package.json and package-lock.json have changed
  • get dependencies and devDependencies in package.json
  • get change log for package.json
  • hold if only devDependencies have changed.
• release otherwise

All tools are nicely suited for creating simple JWT, but having the configs for multiple recipients on one command line is tricky at best.

What we should have is a token tool that consumes a JSON or YAML file for the different parameters of our token. The tool would have a configuration parameter and accept payload and thats it. This allows one to declare the JWT outcome separately from running the command.

The following example illustrates how a declaration might look like:

jose:
  format: compact
  # global claims and defaults
  iat: now
  exp: 1h
  jwks: my/jwks/default.jwks
  sign:
    - jwks: my/jwks/file.jwks
       kid: mysignkey
       alg: RS256
      # other parameters
      aud: for your eyes only
      claims: 
         # application specific claims
    - kid: mydefaultkeyid
       alg: ES256
  enc:
    recipients:
    - jwks: my/friends.jwks
      kid: freds_key
      alg: RSA-OAEP
      # other parameters
      claims: 
         # application specific claims
    - jwks: my/friends.jwks
      kid: lauras_key
      alg: RSA-OAEP
      # other parameters
      claims: 
         # application specific claims

This will allow users to declare what their token should look like and the tool will create a suitable token.

• The tool should be able to select appropriate default values if configuration is missing.
• The tool should override bad statements (like the format in the example above) with suitable one.

Currently the only way to pass a JWS into the verify tool is either via STDIN or via a file.

It would be handy, if the tool would accept the token string directly from input.

This could be done by using a dedicated parameter -T or --JWT or --JWS to pass the string. In this case the tool must not try to read the token from stdin or a file. This way we do not need to verify whether a string is a token or a filename.

Add basic and extended support via the --crit option

Basic support should accept a comma separated list of header claims.

Extended support should accept Key-value pairs and run crit-header functions to validate an incoming JWT.

Crit header support is necessary for validate and decrypt.

The readfile helper requires superagent, which it should not

Hello!

I was curious about the network traffic that is emitted every single time I run newkey with npx.

1. What is it for?
2. Is there any way to disable it and make this a 100% offline operation?

Cheers.

The addkey tests sometimes fail due to timing conditions of Promises.

The tests should be written in a way that are agnostic to the timing of the promises.

Multiple keys require key wrapping alg. (Eg not ecdh-es but ecdh-es-...)

• test for RSA and EC keys
• test for multiple recipients sane headers
• Test for multiple recipients with differen headers
• test for multiple recipients with different key types and headers
• verify that mixing key types is not allowed.

Zsh allows tools to register their sub commands for auto (tab) expansion.

It would be great to have a shell-install-tool that allows users to register jose tools into the environment.

The tools should not require that algorithms are explicity mentioned. Instead sign and encrypt should select suitable defaults if alg or enc are missing.

right now jose crashes ungracefully if no tool is provided.