[spec] clarifications on HTTP hyperlink recipients in CLI about age HOT 5 CLOSED

Yup, those are good questions. I agree on requiring HTTPS, and not having an --insecure flag (you can always curl the file down and then use it if you really want).

On 3️⃣, it's maybe a little too magic. Let's not do it for now.

from age.

1️⃣ In rage I explicitly match on https:// to detect a URL argument, and have no plans to support plaintext HTTP.

2️⃣ It depends on what properties of TLS certificates we (or more precisely, our users) are relying on. An invalid or expired cert is effectively no different from an authentication point of view to plaintext HTTP, but it does still encrypt the keys in transit and prevents MitMing.

From a UX perspective, encrypting to a URL implies encrypting to the identity associated with that URL. It's debatable whether any TLS certificates provide a good notion of identity-binding, but assuming that domain validation is "sufficient", it seems to me like we should lean towards "fail-closed and require user to request out-of-band that URL be fixed", given the overall intent of confidentiality.

3️⃣ I decided not to implement this originally in rage, but I'm open to doing so as long as there is good documentation ensuring it is well-known 🥁 🔔

from age.

Thanks for the input, @str4d. I agree with you on all points.

from age.

Updated the spec. Note that HTTPS recipient lists are not recursive (so they can't link to other HTTPS recipients, nor to files of course) just like file recipient lists are not recursive.

Once the spec moves to a proper man page I'll specify the format better, but it's the same as private key files: all lines must be recipients, empty, or # comments.

from age.

(Let's move further spec discussions to the mailing list. https://groups.google.com/d/forum/age-dev)

from age.