latchset / jose Goto Github PK

View Code? Open in Web Editor NEW

160.0 160.0 47.0 1.49 MB

C-language implementation of Javascript Object Signing and Encryption

License: Apache License 2.0

C 93.06% Shell 5.68% Meson 1.26%

jose's People

Contributors

$rjpontefract avatar$

Stargazers

Watchers

Forkers

simo5 tiran hughsonz puiterwijk tiboris enetanel martinezjavier hkleynhans tpetazzoni mtottenh radosroka mazingr maage dthaler bontouch oleshii zcf1810 sergio-correia david-zhu-corelight dhodovsk neheb truepic ujjwalsh sanjaymsh kishorkunal-raj rharken imirkin frumioj hdholm sarroutbi xiaohuilam hawk259 cotequeiroz rnshah9 mayhemheroes eli-schwartz arakitsuyoshi joelone grooverdan gringo2 nikkicoon zhutony tuliom sunil-dhayal kloczek clauderobi

jose's Issues

self tests are failing on Travis

make check is failing on Travis, see https://travis-ci.org/tiran/pyjose/builds/164060691 . OpenSSLs test suite is passing.

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
OpenSSL 1.0.2j
jansson 2.9
jose master (HEAD)

==============================
   jose 4: ./test-suite.log
==============================

# TOTAL: 6
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/rfc7515_A
=====================

+trap exit ERR
trap: ERR: bad trap
+prfx=./tests/vectors/rfc7515_A
+cmd/jose ver -i ./tests/vectors/rfc7515_A.1.jwsc -k ./tests/vectors/rfc7515_A.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.2.jwsc -k ./tests/vectors/rfc7515_A.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.3.jwsc -k ./tests/vectors/rfc7515_A.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.4.jwsc -k ./tests/vectors/rfc7515_A.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk ./tests/vectors/rfc7515_A.6.2.jwk
No signatures validated!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset -k ./tests/vectors/rfc7515_A.1.jwk
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk -k ./tests/vectors/rfc7515_A.6.2.jwk
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk -k ./tests/vectors/rfc7515_A.6.2.jwk -k ./tests/vectors/rfc7515_A.1.jwk
Signature validation failed!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.7.jwsf -k ./tests/vectors/rfc7515_A.7.jwk
No signatures validated!
FAIL tests/rfc7515_A (exit status: 1)

FAIL: tests/rfc7520_4
=====================

+trap exit ERR
trap: ERR: bad trap
+prfx=./tests/vectors/rfc7520_4
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsc -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsf -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsg -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsc -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsf -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsg -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsc -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsf -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsg -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsc -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsf -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsg -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsc -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsf -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsg -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsc -k ./tests/vectors/rfc7520_4.6.jwk
Invalid JWS!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsf -k ./tests/vectors/rfc7520_4.6.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsg -k ./tests/vectors/rfc7520_4.6.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsc -k ./tests/vectors/rfc7520_4.7.jwk
Invalid JWS!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsf -k ./tests/vectors/rfc7520_4.7.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsg -k ./tests/vectors/rfc7520_4.7.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.jwkset
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.3.jwk
No signatures validated!
FAIL tests/rfc7520_4 (exit status: 1)

FAIL: tests/rfc7520_5
=====================

+prfx=tests/vectors/rfc7520_5
+cmd/jose dec -i tests/vectors/rfc7520_5.1.jwec -k tests/vectors/rfc7520_5.1.jwk
Decryption failed!
+cat tests/vectors/rfc7520_5.1.pt
+test  == You can trust us to stick with you through thick and thinâ€“to the bitter end. And you can trust us to keep any secret of yoursâ€“closer than you keep it yourself. But you cannot trust us to let you face trouble alone, and go off without a word. We are your friends, Frodo.
./tests/rfc7520_5: 5: test: unexpected operator
FAIL tests/rfc7520_5 (exit status: 2)

FAIL: tests/rfc7638
===================

+trap exit ERR
trap: ERR: bad trap
+cmd/jose thp -i tests/vectors/rfc7638_3.1.jwk -H sha256
Unsupported hash function!
jose pub -i JWK(Set) [-o JWK(Set)]

Calculates the JWK thumbprint.

    -i FILE,   --jwk=FILE       JWK or JWKSet input (file)
    -i -,      --jwk=-          JWK or JWKSet input (stdin)

    -H sha1,   --hash=sha1      Use SHA1 as the hash function
    -H sha224, --hash=sha224    Use SHA224 as the hash function
    -H sha256, --hash=sha256    Use SHA256 as the hash function
    -H sha384, --hash=sha384    Use SHA384 as the hash function
    -H sha512, --hash=sha512    Use SHA512 as the hash function

    -o FILE,   --output=FILE    JWK or JWKSet output (file)
    -o -,      --output=-       JWK or JWKSet output (stdout; default)

+cat tests/vectors/rfc7638_3.1.thp
+test  == NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
./tests/rfc7638: 5: test: unexpected operator
FAIL tests/rfc7638 (exit status: 2)

FAIL: tests/jose
================

+ASIGN=RS256 RS384 RS512 ES256 ES384 ES512 PS256 PS384 PS512
+SSIGN=HS256 HS384 HS512
+AWRAP=ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW RSA1_5
+SWRAP=A128KW A192KW A256KW A128GCMKW A192GCMKW A256GCMKW
+SENCR=A128CBC-HS256 A192CBC-HS384 A256CBC-HS512 A128GCM A192GCM A256GCM
+tests/rsa_oaep
+AWRAP=ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW RSA1_5 RSA-OAEP RSA-OAEP-256
+mktemp -d
+tmpdir=/tmp/tmp.9p01yZzbya
./tests/jose: 15: ./tests/jose: Syntax error: "(" unexpected
FAIL tests/jose (exit status: 2)

Condiseration for JWK <-> OpenPGP Formats?

It might be a nice idea to try and support integration between keys created by gpg and jose

e.g.

jose jwk fmt -I keyring.gpg -o keyring.JWKset

As far as I can see there are very few tools that interopt with public/private keys formatted in the OpenPGP format, this could be an opportunity to fix that.

Integrating into Obj-C iOS Project

Hi there!

I'm needing to integrate Jose functionality into my iOS project. I found this library and would like to try it out. However, when I pull all the source files into my project and attempt to compile, I get an error around #include <jansson.h>.

Is there a step I'm missing for getting this project organized to integrate into iOS? I cannot find a jansson.h file within the project. Google indicates that it is part of a separate library, but I am unsure of how to integrate it with this library.

Any help with fixing these issues would be appreciated! Thanks!

Incorrect salt length for RSASSA PSS signatures

The wrong salt length value is being used for RSASSA PSS signatures.

RFC 7518 (JWA) says the following:

3.5. Digital Signature with RSASSA-PSS

This section defines the use of the RSASSA-PSS digital signature
algorithm as defined in Section 8.1 of RFC 3447 [RFC3447] with the
MGF1 mask generation function and SHA-2 hash functions, always using
the same hash function for both the RSASSA-PSS hash function and the
MGF1 hash function. The size of the salt value is the same size as
the hash function output. All other algorithm parameters use the
defaults specified in Appendix A.2.3 of RFC 3447.

The code in rsassa.c that generates signatures (sign()) fails to call EVP_PKEY_CTX_set_rsa_pss_saltlen() and therefore uses the default salt length value which is the maximum salt length. This goes against the JWA specification which says that the salt length must be the same as the hash length. Passing a value of -1 to EVP_PKEY_CTX_set_rsa_pss_saltlen() rectifies this issue.

accept base64 encoding?

Please feel free to close if you disagree.

I have been working around a misbehaving service that produces JWKs with standard base64 encoded data for the 'k' field instead of base64 urlsafe encoded data (minus padding) as the standard suggests.

I have a patch that would let the base64 decoder accept either data formats. I can see arguments for not accepting this upstream (as it doesn't strictly conform to the RFC), but I figured I'd raise it as an issue and see how things shake out.

jose-fmt: Please warn about or remove parameter order significance

Hello,
perhaps a short example already demonstrates the point:

echo '{"key":"value"}' | jose fmt --json=- --object --get key --unquote=-
value

echo '{"key":"value"}' | jose fmt --json=- --unquote=- --object --get key

In other words, placing the --unquote output parameter before the --get operation yields in no output at all.

So I'm asking to to either make parameter order irrelevant for jose's operation, at least where possible - I know in some places like the clevis pins order is significant. Or - easier but less user-friendly - place a warning in each manpage about this.

Encryption with jose_jwe_enc() (alg=ECDH-ES+A256KW, enc=A256GCM) and Compact Serialization

Use jose_jwe_enc() to encrypt with alg=ECDH-ES+A256KW and enc=A256GCM.
I want to use that data for Compact Serialization (Compact Serialization is currently implemented independently).

The result of Encrypting with jose_jwe_enc() is as follows.

"protected":"～",
"header":{
"epk":{
"kty":"EC",
"crv":"P-256",
"x":"～",
"y":"～"
}
},
"encrypted_key":"～",
"iv":"～",
"tag":"～",
"ciphertext":"～"

CompactSerialization cannot use the header object,The epk object must be inserted protected.
Is there a way to insert an epk object into protected and not create a header object?
(The pattern of alg=RSA-OAEP-256, enc=A256GCM works with the original implementation of Compact Serialization.)

A256GCM decryption fails for IV length not equal to 12

In lib/openssl/aesgcm.c:

o o o
301 static jose_io_t *                                                              
302 alg_encr_dec(const jose_hook_alg_t *alg, jose_cfg_t *cfg, const json_t *jwe,    
303              const json_t *cek, jose_io_t *next)                                
304 {                                                                               
305     const EVP_CIPHER *cph = NULL;                                               
306     jose_io_auto_t *io = NULL;                                                  
307     io_t *i = NULL;                                                             
308                                                                                 
309     switch (str2enum(alg->name, NAMES, NULL)) {                                 
310     case 0: cph = EVP_aes_128_gcm(); break;                                     
311     case 1: cph = EVP_aes_192_gcm(); break;                                     
312     case 2: cph = EVP_aes_256_gcm(); break;                                     
313     default: return NULL;                                                       
314     }                                                                           
315                                                                                 
316     uint8_t iv[EVP_CIPHER_iv_length(cph)]; 
317                                                                                 
318     if (jose_b64_dec(json_object_get(jwe, "iv"), NULL, 0) != sizeof(iv))        
319         return NULL;                                                            
320                                                                                 
o o o

the condition evaluated at LINE=318 always fails for IV lengths not equal to 12.

I believe the condition must test a range of values -- not just 12.

OpenSSL cannot recognize the private key after converting jwk → pem

Generate an RSA (3072) private key with OpenSSL and operate as follows.

1."pem → jwk" conversion with the following API
jose_openssl_jwk_from_EVP_PKEY()

2."jwk → pem" conversion with the following API(jwk was generated in 1.)
jose_openssl_jwk_to_EVP_PKEY()

3.Generate pem file with OpenSSL

4.Read pem file of 3. by rsa command of OpenSSL
→Read failure

Possibly implement a jwe hdr subcommand

The clevis unlockers use the idiom

read -r -d . hdr

to read the heaader of the jwe on stdin, and the header only.

Now I'd like to move that logic to jose since the above way

deals with jwe internals that should not be visible on this layer,
is therefore not easy to understand, and
is a bashism which is really hard to eliminate¹².

As a solution I propose a new subcommand that does the same. The above statement would be rewritten as

hdr="$(jose jwe hdr --input=- --output=-)"

and I consider that an improvement.

¹ Since all solutions that are around slurp the entire input, something I want to avoid at any cost.
² I managed to replace all the other bashsims, you'll find that as an clevis issue soon.

Consideration for JWK <-> PEM formats

I was curious if you guys considered having a conversion build in for JWK <-> PEM formats? Perhaps even extension based so that if -o whatever.pem ended in PEM then you would use that format.

The calculation for the length of b64 buffers is incorrect

In commit 285327a you rewrote the calculation on length of a b64 encoded/decoded string. In the jose_b64_decode the test to handle the "0" return from the jose_b64_dlen is not taken into account when decoding. So when an illegal padded string is presented, the program coredumps on the fact that the buffer is 0-size but the decoding is done in jose_b64_decode_buf based on the zero terminated string not on the length of the buffer.

[minor] Malformatted jose-jwe-enc manpage

Hello,
can you please check man ./doc/ronn/jose-jwe-enc.1? The last example "Encrypt with two keys and two passwords" is not properly formatted. I guess there's a missing newline in the related .md

Maintenance status of this project

Hi all,

I would like to know the current status of this project, maintenance-wise.
would you please provide some info in this regard.

Regards,

Jose unable to parse setting containing an array

Discovered in latchset/clevis#102

Clevis is failing to create a TPM PCR Policy to enforce platform integrity state through Jose when the number of selected pcrs_ids is more than one, and an array is passed to the configuration.

From @martinezjavier comment:

$ jose fmt -j- -Og pcr_ids -u- <<< '{"pcr_bank":"sha1","pcr_ids":"16"}'
16
$ echo $?
0

$ jose fmt -j- -Og pcr_ids -u- <<< '{"pcr_bank":"sha1","pcr_ids":["16"]}'
$ echo $?
4

Apparently, Jose is not happy with the array notation in pcrs_ids.
Due to this, on Clevis, when using more than one PCR to declare the policy, it silently fails to parse the config, and create the LUKS key slot without any PCR policy silently

Jose Version: jose-10-3.fc29.x86_64

`-t` is an invalid option to `jose jwk gen`

In the README.md the following command is given as an example:

jose jwk gen -t '{"alg": "A128GCM"}' -o oct.jwk

But it seems that -t is no longer a valid option?

"PS256" not supported

While the main README says it's supported, I'm getting

jws.c:306:JOSE_CFG_ERR_ALG_NOTSUP:Signing algorithm (PS256) is not supported

Using the command:

jose jws ver -k private.jwk -i message.jws

message.jws being:

eyJhbGciOiJQUzI1NiJ9.SGVsbG8gd29ybGQh.LyJBXPHYt3B4AJQ_aFfrbkTfEflpooS2gb5zDa4WCfD528udcJ-OBngebtphsG7Z-6bQmcUzz5AEtDJ_qTsrEB8pcIfl0OTNcqUGokkpeBIpukHgYEhVEaJ6TKPIlXbbwdV9Bv7k9vacMphNKJ3E-B9e0Y5iBuGu30pxJlBiQykybh2FAUGAJqYPG1pJxqzWqBSnirnUWe7tOOdNq5H6R0NJEEuwsnlCV27DfEQIM0ILHvJjpSEhAc6TCStcV3V0swvYmxVe8NIhajsYtva1J1M5ZiHKCaGsznktz28rGcJZ0Cf-lJIfr3FC9_eYOeNbEk-APgkWzcdN45VS05uVSA

and private.jwk being

{"alg":"PS256","d":"AnwLtzR4gOIIfraMxK58U-R7ecLqtGIeMoengJ4sNcm36krYZP0cN57LsaXiRvkciASTwXD5TFVAvBEW-39kpvJOmCYE8a1TGNO7nUDVrc9JhSoivilTpER2n9Pmr3S2NPY0jTBebNEYAJIgcM9QDPbLDQ86R7CB0nlMJcogAgjpdceZJBrqaziJuM0MdyuY7pvkwliKKsgAsj8IpYW3kniBg1jVweHeDfXrtovdecVudOG8p6RUMFSZnxd3FYNQJgRaNy7iGh6S1q81Dx9VsFEK2njfjHSdcVF6qj-tT6cgpQ_56JyrzQhd8xsN2uArazNzdZHCejHD9_MrOUOJAQ","dp":"pZe217GZQXg3NIqh1gLmNCo37fko2CCO2kBN5JxHH9fB8aCeT9XyNy4iAvyyWSHkAjsloyJEwBuF2NXxeagb04P4KGX8zVXdANFk6MAsaGDVYs8FT1DhMsH_aRl01tRGEb9ss4MQpq5MkKNAb0Ib7h8mmIevQ7N2ZAE8IRwb8Tk","dq":"kyK-2lqqanoFhBFKP3UVneBbwfHfcdKwX1ivjTJTRettDYzh3aH9Cii44ZaFCS3Ck2MvqgIc8Bz-04kgkMVjqhuCWE7T27a0Lfx3V0PZAkXd_XV9eEZvvh5DZ4St982POvwRBqWOxPpOcSajdPK4ic9QoRnomtMlv6ST2QQ9inE","e":"AQAB","ext":true,"key_ops":["sign"],"kty":"RSA","n":"ofdkpbwFcAJjVKMto8ymSua25Ruet-QjIsNnSL6u2BaAronZ7mNymukTzicGq02f3PjP9lbvsjhLB-8fC88lmo6m_ceT9FrZgLh5HwLIpvObRt9h27BU8nIjC4H_fyrdHaS22TB0FD-zA0If-9zopLaqvgioznXcFzPveG4fncdnoxyfaRThSJwlZmSagvE_j56hIFmTV7TbYe-AHcfCEPE5apHXBXS13XfauCnpuxR1RAHgIvWRUEngaXPOPxGfQxlYXtnV0zmWpgD1x6OEmI-hjouz3sbxLluW8OmL_B_iB7XoS15YjcpOXh6HTaMz4QZDToY1Hof42lrHArzy_Q","p":"0utor0vGesVMZri6pBU3W1X18M99IhLaC-1F9DL8mjZeyd2FI64TOHzUQbqPT5zgIhFDl6e3NiijktGGtRVG-3x8-_c1nd5EtDOX_BWy1YVnlNTjfNG00dbN7YunlA8XBXcojyveeXHUKUuG82FM1iMj040RIJZtWNWLowAwd5k","q":"xJV7LEkXGDfdFe8qUbRUsA5UTvtPaPQsxLKGLbpRqtyW2om8SsFoS9na2mZIxX_s9537r1hcnd94T16cE9JDbR0PvUl70-HFcmx07IodokMDQMu4rTTA1SxeeOnBD9z3IXB6mM2yWvDMpIch28AF_n8FaLSVqZf_7lno0Ld9pQU","qi":"Uq0Z6aOiQHXPfYyAU6gJGpZFBMK8kL175jY69r7Ib4rMCrVqrKQrX_l2ZJmaGwtFMjGdOgBjBt_Rtjuh3e4CRXNj7UzyUDqD2Hn-5_P7PSTGjZYRhSb2mJhVAN8x9Q8G3nuW621_giSTxquTr2AlMvuBSDxke-4kncnnVyYYLiY"}

Include configure script in releases

Release 3 had no configure script and release 4 was not published as a tar ball at all. Please run autoreconf and ship the configure script in source releases.

jose fmt: Please implement shotcuts for operations on deep hashes.

Hello,
fetching a value from a nested hash requires a lot of --get:

echo '{"level1":{"level2":{"level3":{"key":"value"}}}}' | \
    jose fmt --json=- --object  --get level1 --get level2 --get level3 --get key --unquote=-

It was nice if the keys could be concatenated so this can be written in a shorter form like:

echo '{"level1":{"level2":{"level3":{"key":"value"}}}}' | \
    jose fmt --json=- --object  --get level1.level2.level3.key --unquote=-

Bonus: Make the separator (currently: dot) configurable.

Related, it was nice if -U/--unwind could understand an optional repetition value, so (taken from clevis-encrypt-tang):

jwe="$(jose fmt -j "$jwe" -g protected -g clevis -g tang -q "$url" -s url -UUUUo-)"

could be written as

jwe="$(jose fmt -j "$jwe" -g protected -g clevis -g tang -q "$url" -s url -U4 -o-)"

PS: To make sure: This is not at all about short/long parameter names.

Support for compilers other than GCC & Clang

I have been trying to build jose using Oracle (Sun) Studio CC and IBM xlc. configure.ac specifiesa lot of warning flags which are GCC specific. (I guess Clang accepts these too.) The primary issue I run into though is that jose depends on the json_auto_t which depends on a compiler extension in Clang & GCC.

Using json_auto_t was adopted in change 803f0b4. I am also not sure if there would be a similar extension on Visual Studio that support this.

Is support for other compilers something that would be considered, or is this project purely targeted at GCC?

Implement JWS Unencoded Payload

https://tools.ietf.org/html/rfc7797

No algorithms returned

./jose alg
returns nothing. I guess this is the main reason why I can't generate any keys, load from file, encrypt nor decrypt.
Do I need to load the supported algos somehow or what am I doing wrong?

Make jose_jwk_allowed() have a strict mode

Currently, jose_jwk_allowed() returns true if the JWK contains none of the appropriate attributes. A strict mode would fail in this case.

Per-algorithm type query in jose sup

The jose sup command should have the ability to query specific types of algorithms and get a newline delimited output. For example:

$ jose sup -H
sha1
sha224
sha256
sha384
sha512

This makes it much easier to use for scripting. See for example: https://github.com/latchset/tang/blob/master/tangd-update#L23

Port OpenSSL code to use contemporary API

Port Jose code to use contemporary OpenSSL API, allowing to use external engines and algorithms provided by them.

Implement JWT (RFC 7519)

This is not yet implemented.

jose_jwk_gen() fails with static linking

I have a runtime problem with Jose-9 ...

When statically linked, the following trivial program detects a runtime error on jose_jwk_gen(). The same program detects no error when dynamically linked.

$ cat test_jose_jwk_gen.c 
#include <jose/jose.h>

int main()
{
    json_auto_t* jwk = json_pack("{s:s}", "alg", "ES256");
    if (jwk == NULL)
        printf("Error: json_pack()\n");

    if (jose_jwk_gen(NULL, jwk) == false)
        printf("Error: jose_jwk_gen()\n");

    return 0;
}

W o r k s - - - ( D y n a m i c L i n k i n g )

$ gcc -o test_jose_jwk_gen test_jose_jwk_gen.c -I$THIRD_PARTY/jose/linux64-x86/include -I$THIRD_PARTY/jansson/linux64-x86/include -L$THIRD_PARTY/jose/linux64-x86/lib -ljose -L$THIRD_PARTY/jansson/linux64-x86/lib -ljansson -L$THIRD_PARTY/openssl/linux64-x86/lib -lcrypto
$ ldd test_jose_jwk_gen
        linux-vdso.so.1 =>  (0x00007ffc10584000)
        libjose.so.0 => $THIRD_PARTY/jose/linux64-x86/lib/libjose.so.0 (0x00007f300eb4f000)
        libjansson.so.4 => $THIRD_PARTY/jansson/linux64-x86/lib/libjansson.so.4 (0x00007f300e941000)
        libcrypto.so.1.0.0 => $THIRD_PARTY/openssl/linux64-x86/lib/libcrypto.so.1.0.0 (0x00007f300e50e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f300e126000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f300df0f000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f300dcf3000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f300daef000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f300ed6c000)
$ ./test_jose_jwk_gen 
<no error>

F a i l s - - - ( S t a t i c L i n k i n g )

$ gcc -o test_jose_jwk_gen test_jose_jwk_gen.c -I$THIRD_PARTY/jose/linux64-x86/include -I$THIRD_PARTY/jansson/linux64-x86/include -Wl,-Bstatic -L$THIRD_PARTY/jose/linux64-x86/lib -ljose -L$THIRD_PARTY/jansson/linux64-x86/lib -ljansson -Wl,-Bdynamic -L$THIRD_PARTY/openssl/linux64-x86/lib -lcrypto
$ ldd test_jose_jwk_gen
        linux-vdso.so.1 =>  (0x00007ffeb117d000)
        libcrypto.so.1.0.0 => $THIRD_PARTY/openssl/linux64-x86/lib/libcrypto.so.1.0.0 (0x00007f5a60334000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5a5ff4b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5a5fd47000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5a60768000)
$ ./test_jose_jwk_gen 
Error: jose_jwk_gen()

The makefile to build the Jose git-submodule looks like:

$(TARGET_NAME) :
    @$(ECHO) "Creating $@."
    @$(CD) repo; \
    autoreconf --install; \
    export jansson_CFLAGS="-I../../../jansson/$(PLATFORM)-$(PROCESSOR)/include"; \
    export jansson_LIBS="-L../../../jansson/$(PLATFORM)-$(PROCESSOR)/lib -ljansson"; \
    export libcrypto_CFLAGS="-I../../../openssl/$(PLATFORM)-$(PROCESSOR)/include"; \
    export libcrypto_LIBS="-L../../../openssl/$(PLATFORM)-$(PROCESSOR)/lib -lcrypto"; \
    ./configure --enable-static --prefix=$(THIRD_PARTY)/jose/linux64-x86; \
    $(MKDIR) $(THIRD_PARTY)/jose/linux64-x86; \
    $(MAKE) CFLAGS="-g -O2 -m$(BUS)"; \
    $(MAKE) install

and the Jansson git-submodule's makefile looks like:

$(TARGET_NAME) :
    @$(ECHO) "Creating $@."
    @$(CD) repo; \
    autoreconf --install; \
    ./configure --prefix=$(THIRD_PARTY)/jansson/linux64-x86; \
    $(MAKE) CFLAGS="-g -O2 -m$(BUS)" -fPIC; \
    $(MKDIR) $(THIRD_PARTY)/jansson/linux64-x86; \
    $(MAKE) install

Platform info:

$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
o o o

$ cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core)

Error with make

I can not do make, owing to this error:
$ make
CC lib/openssl/libjose_openssl_la-jwk.lo
lib/openssl/jwk.c:29:1: error: unused function 'EVP_PKEY_cleanup' [-Werror,-Wunused-function]
declare_cleanup(EVP_PKEY)
^
lib/openssl/misc.h:35:5: note: expanded from macro 'declare_cleanup'
type ## _cleanup(type **p) {
^
:135:1: note: expanded from here
EVP_PKEY_cleanup
^
1 error generated.
make: *** [lib/openssl/libjose_openssl_la-jwk.lo] Error 1

Eliminate use of an enum for JWK Type

JWK Type as an enum will make it impossible to handle uknown key types and require changes in the API if a new key type is created.

Detect correct jansson version

configure does not detect and fail if jansson is < v2.9

Support for Windows ?

I couldn't detect if the project was being actively compiled and used on Windows. Is there a plan ?

test scripts assume that /bin/sh is bash

The test scripts assume that /bin/sh is a bash compatible shell. Debian (Travis CI) uses a simpler shell that only implements sh.

trap exit ERR
trap: ERR: bad trap

function onexit() {
    rm -rf $tmpdir
}
./tests/jose: 15: ./tests/jose: Syntax error: "(" unexpected

THANK YOU

OK technically this is not an issue, feel free to close it. But thank you so much for writing this software! I have been trying to make keys and sign messages thus far with javascript and python libraries and they just didn't work right. This program did RSA256 signing perfectly on the first shot and was so easy to use with just regular files. You guys are the best.

🎆

Changing ephemeral key type for JWEs

Is there a way to choose what encryption scheme is used for the CEK of a JWE? I noticed it always defaults to AES-CBC and I can't find any option or way (by glancing at the code) to use, say, AES-GCM or direct mode.

Implement JWK Thumbprints

https://tools.ietf.org/html/rfc7638

I can not use Jose for iOS project

Hi, first thank you for developer this library, is very helpfull.
I've added all dependences, Jannson(libjannson.a), openssl (libcrypto.a and libssl.a)
I'm having problems with compile my iOS project with this error:

Undefined symbols for architecture x86_64:
"_jose_openssl_jwk_from_RSA", referenced from:
+[JweManager rsaToJwk:] in JweManager.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Anyone could help me?

Thank you

exported version number python/C

As an application, I want to be able to on compile-time detect which version of the library is being used, so I can write code that is compatible with different API versions.

Add symbol versioning

We'd like to be able to change API in the future if we need. This requires symbol versioning.

Use Wrap/Unwrap instead of Seal/Unseal

The Jose RFCs use Key Wrap and Key unwrap to refer to key wrapping like operations, the API should reflect that language so that a user can directly relate the two concepts

Portability of the library and json_auto_t type

in 803f0b4 there was a dependency on a gcc specific cleanup feature that was introduced. This seems to have broken an otherwise portable C library.
But moreover akheron/jansson library which introduced this json_auto_t type did so within a ifdef check for GCC where as in this library it wasnt. Can we please introduce preprocessor guards to stop this feature from breaking the portability of the library?

Allow empty CEK in input to the wrap function

An Empty CEK would cause internal generation and allows to detect that the ECDH-DS function should fail (as it cannot deal with a pre-generated CEK anyway.

Improvement: Add a link to HTML API docs from the README.md

It may be useful to have a link to the API docs. Browsing to them in the source archive provides raw HTML output which is not great.

Create public JWK from X.509 cert

It would be useful to create a RSA/EC JWK from a X.509 cert or a PKey.

Allow global white-lists for encryption/signing algorithms

This way a user can set the allowed algorithms globally and not risk unvalidated input to cause the use of algorithms not deemed acceptable for an application.

jose cli - Poor feedback on error

I tried to generate a key using the following command:

./jose jwk gen -i '{"alg": "RS256"}'  -o mykey.jwk

And various variations on that theme. But the only response I seem to be able to get is JWK generation failed!. It would be nice if the tool helped a bit and let you know what you are doing wrong.

Add to homebrew

Homebrew is a very popular package manager for macOS and I think it would be great if josé was distributed through it!

https://brew.sh/

OSX build on Travis-ci is failing

Hi ,

OSX build for 'AMD64' for below 'env' is failing:
- DISTRO=osx:xcode8.3
- PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig:/usr/local/opt/zlib/lib/pkgconfig

Log Summary:
"==> ./bootstrap --prefix=/usr/local/Cellar/cmake/3.18.2 --no-system-libs --paral
==> make
The job exceeded the maximum time limit for jobs, and has been terminated. "

Full error log can be tracked on the link: https://travis-ci.com/github/sanjay-cpu/jose/jobs/382685852

Please someone look into the issue.

Thanks !!

Typos in manpages and other places

Again, reported by Debian's lintian checker:

inferrence -> inference
miscelaneous -> miscellaneous

Found in:

doc/doxygen/man/man3/jose_cfg.3
doc/doxygen/man/man3/jose_jwe.3
jose/cfg.h
jose/jwe.h

Building on OSX

When trying to build on OSX I'm running into bash syntax error:

$ autoreconf -if && ./configure
glibtoolize: putting auxiliary files in '.'.
glibtoolize: copying file './ltmain.sh'
glibtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
glibtoolize: and rerunning glibtoolize and aclocal.
glibtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:4: installing './compile'
configure.ac:6: installing './missing'
cmd/Makefile.am: installing './depcomp'
checking build system type... x86_64-apple-darwin15.6.0
checking host system type... x86_64-apple-darwin15.6.0
checking target system type... x86_64-apple-darwin15.6.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin15.6.0 file names to x86_64-apple-darwin15.6.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin15.6.0 file names to toolchain format... func_convert_file_noop
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin15.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
./configure: line 12097: syntax error near unexpected token `0.25'
./configure: line 12097: `PKG_PROG_PKG_CONFIG(0.25)'

I may just be going about building this the wrong way, in which case which is the right way?

Compact serialization support for JWE API similar to specifying flag -c in command line

I know that calling jose jwe enc -c -I pt.txt -k rsa_pub.jwk from command line gives a compact serialized output. Is it possible to obtain a similar output from the function jose_jwe_enc in jwe.h? How to achieve it if the purpose is not command line execution but simple function calls from a program?