On Fri, 9 Aug 2019 at 07:27, François Kooman <fkooman@xxxxxxxxx> wrote:
On 09.08.19 12:19, Petr Pisar wrote:
> An algorithm that will be obsoleted by another modern algorithm in ten years. No
> this is not how cryptographical tools should be designed. The tool and the
> singature format must be agnostic to a concrete algorithm.
Actually. It is not designed like this, see [1] for the signature/key
format.
> This is an invalid argument. You can always found an arbitrarily old
> distribution that does not support a feature of your choice.
Fair enough, it is not an argument against using OpenSSL, just against
using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for
signatures and not RSA or ECDSA.
> There is no explanation why. Only a "don’t use a low-level crypto library like
> OpenSSL or BouncyCastle" statement. Do you have any explanation?
Okay, we are getting a bit off-topic here :-)
Using a low level crypto library like OpenSSL is a bad idea for
developers. It gives them a huge foot gun. I know enough not to want to
use the OpenSSL API as a developer. I will screw it up. I'm confident I
can write an application using libsodium without the crypto
implementation being the weak part. I'm sure that's true for most (all?)
developers that are not also OpenSSL developers...
> Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best
tool for doing TLS. For all other purposes it is not the best tool. So
introducing something like libsodium for non-TLS purposes seems like a
good thing to do! Especially if this means dropping the OpenSSL/GnuPG
dependency...
I don't know what the reasons are for arguing against libsodium for
non-TLS crypto use cases, maybe the foreseen (long term) potential costs
in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
One of many arguments is that whatever protocol set used to sign artifacts has to be audited by various outside agencies in Europe/US/etc to be used on their systems. That costs time and money to do. Certain tools are already audited like openssl so using them is easier to get added to an ongoing certification than something which is not audited like libsodium. If it hasn't been part of an ongoing certification, libsodium would need to be started from the ground up and probably take 2-3 years. Until it is done, there would be considerable 'push-back' from various consumers of Fedora from just French government agencies of using it as part of something they would allow for usage. That has a pile-on effect as industries wanting to work with said agencies can't use the OS in certain places, which boils out as a 4-5 year time where the signing is in limbo.
This is the part that Petr is not diplomatically covering in that the protocol for signing needs to be past and future reliable. The tool writer needs to know that it is a long haul of working with existing crap for a long time until it can hopefully be removed in 5-10 years when whatever audits and certs are done.
Cheers,
François
[1] https://jedisct1.github.io/minisign/
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Stephen J Smoogen.
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
