Is this project still maintained?

[tuupola]

Last commit seems to be three years ago. Is it safe to assume spec is not maintained anymore?

[davesque]

Why is no maintainer responding to these questions? There are multiple outstanding issues with the spec (signing key length, ambiguous versioning, race conditions with revocation events to name a few) and it doesn't appear that any official party has noticed or responded to any of them. No reasonable developer should feel safe in using this spec.

[alex]

Please don't over-dramatize this. I'm a developer on one of the larger downstreams of this spec, and while there's plenty of cleanups, improvements, and clarifications I'd like to land, they're far from critical, and I still enthusiastically recommend people use Fernet over the hand-rolled nonsense that it generally replaces (no MAC, mac-then-encrypt, weirdo padding, default IVs, etc.)

[davesque]

Sorry about that. But it's a problem that there doesn't seem to be much activity here. It's also difficult to understand what organizations or individuals are responsible for working things out. Maybe that could be added to the README? I saw some discussion about the inactivity issue over at pyca/cryptography. Are there any other projects that have a hand in this document?

[tuupola]

Anyone coming here I would love to hear feedback on Branca which is basically an IETF XChaCha20-Poly1305 AEAD version of Fernet.

[firegurafiku]

@alex

I still enthusiastically recommend people use Fernet over the hand-rolled nonsense that it generally replaces (no MAC, mac-then-encrypt, weirdo padding, default IVs, etc.)

Could you please explain what's wrong with authenticating after encryption? It seems like RFC7519 has directly opposite opinion.

11.2.  Signing and Encryption Order

   While syntactically the signing and encryption operations for Nested
   JWTs may be applied in any order, if both signing and encryption are
   necessary, normally producers should sign the message and then
   encrypt the result (thus encrypting the signature).  This prevents
   attacks in which the signature is stripped, leaving just an encrypted
   message, as well as providing privacy for the signer.  Furthermore,
   signatures over encrypted text are not considered valid in many
   jurisdictions.

[alex]

Encrypting and then authenticating is fine, I was deriding the opposite, authenticating and then encrypting.

…

On Sat, Mar 17, 2018 at 12:54 PM, Pavel Kretov ***@***.***> wrote: @alex <https://github.com/alex> I still enthusiastically recommend people use Fernet over the hand-rolled nonsense that it generally replaces (no MAC, mac-then-encrypt, weirdo padding, default IVs, etc.) Could you please explain what's wrong with authenticating after encryption? It seems like RFC7519 <https://tools.ietf.org/html/rfc7519> has directly opposite opinion. 11.2. Signing and Encryption Order While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBDu3JpUmFJ3B77Ywij009U-AHPg8ks5tfT-qgaJpZM4NT29H> .

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[firegurafiku]

@alex
Sorry, it's me who messed things up: my original message should read «with encryption after authentication». The quoted RFC's fragment states that it's preferred to authenticate the plaintext first, and then encrypt it combined with the signature.

[alex]

https://moxie.org/blog/the-cryptographic-doom-principle/

…

On Sat, Mar 17, 2018 at 1:06 PM, Pavel Kretov ***@***.***> wrote: @alex <https://github.com/alex> Sorry, it's me who messed things up: my original message should read «with encryption after authentication». The quoted RFC's fragment states that it's preferred to authenticate the plaintext first, and then encrypt it combined with the signature. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBF90MOZDflRshfis0a3150e_AYx2ks5tfUKRgaJpZM4NT29H> .

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6