On 13/04/17 14:39, Steffan Karger wrote: > On 12-04-17 13:35, Steffan Karger wrote: >> Version 2.4.1 >> ============= >> - - ``--remote-cert-ku`` now only requires the certificate to have at least >> the >> - bits set of one of the values in the supplied list, instead of requiring >> an >> - exact match to one of the values in the list. >> - - ``--remote-cert-tls`` now only requires that a keyUsage is present in the >> - certificate, and leaves the verification of the value up to the crypto >> - library, which has more information (i.e. the key exchange method in use) >> - to verify that the keyUsage is correct. >> - - ``--ns-cert-type`` is deprecated. Use ``--remote-cert-tls`` instead. >> - The nsCertType x509 extension is very old, and barely used. >> - ``--remote-cert-tls`` uses the far more common keyUsage and >> extendedKeyUsage >> - extension instead. Make sure your certificates carry these to be able to >> - use ``--remote-cert-tls``. >> +- ``--remote-cert-ku`` now only requires the certificate to have at least >> the >> + bits set of one of the values in the supplied list, instead of requiring >> an >> + exact match to one of the values in the list. >> +- ``--remote-cert-tls`` now only requires that a keyUsage is present in the >> + certificate, and leaves the verification of the value up to the crypto >> + library, which has more information (i.e. the key exchange method in use) >> + to verify that the keyUsage is correct. >> +- ``--ns-cert-type`` is deprecated. Use ``--remote-cert-tls`` instead. >> + The nsCertType x509 extension is very old, and barely used. >> + ``--remote-cert-tls`` uses the far more common keyUsage and >> extendedKeyUsage >> + extension instead. Make sure your certificates carry these to be able to >> + use ``--remote-cert-tls``. >> +- The new option ``--tls-cert-profile`` can be used to restrict the set of >> + allowed crypto algorithms in TLS certificates in mbed TLS builds. The >> + 'legacy' profile can be used to re-enable support for SHA1 and 1024-bit >> RSA >> + keys. > > Hrmpf, this should of course get a new section '2.4.2'... Let me know > if you want a v3, or whether this can be fixed on-the-fly. Apologies!
No problem. I don't mind moving things to a 2.4.2 section. I'm however a bit puzzled of the "non-changes" (well, the indenting is changing, unless I'm blind to other changes) to --remote-cert-cu, --remote-cert-tls and --ns-cert-type. If we want to change the indenting, I think that should be kept in a separate patch, and keep --tls-cert-profile as a patch of its own. Otherwise, Changes.rst tools fine to me. On a more generic note to this patch. I wonder if we should keep "legacy" the default in the v2.4 branch. In the Fedora 26 (and Rawhide/27) builds I had to do something similar [1] to keep users happy. As OpenVPN isn't ready for OpenSSL v1.1, I had to switch to mbed TLS. Unfortunately that haven't been as successful as I really hoped it would be, but that's an entirely different story (and mail thread). As long as the Fedora builds need to be built with mbed TLS, I will need to ensure 'legacy' is the default there for a while. For the coming Fedora Rawhide (which will be F28), I can make some announcements preparing users to move to stricter defaults. [1] <http://pkgs.fedoraproject.org/cgit/rpms/openvpn.git/tree/0001-workaround-Allow-weaker-RSA-keys-and-MD-algorithms-i.patch?h=f26> -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
