proposal: crypto/x509: support extending list of algorithms

[denisvolin]

What version of Go are you using (go version)?

-- go1.12.4

Does this issue reproduce with the latest release?

-- Probably, yes too.

What operating system and processor architecture are you using (go env)?

-- Linux, amd64

What did you do?

Used a test.cer file which contains encoded pkix certificate using GOST 34.10-2001 algorithm
and attempted to extract the name with:

package main

import (
      "io"
      "os"
      dio "custom/package"
)

func main() {
	file, err := os.Open("test.cer")
	if err != nil {
		fmt.Println("file opening error:", err)
		return
	}

	defer file.Close() //nolint:errcheck

	data, err := dio.ReadOut(file) // reads out the io.Reader until an error
	if err != nil && err != io.EOF {
		fmt.Println("file reading error:", err)
		return
	}

	cert, err := x509.ParseCertificate(data)
	if err != nil {
		fmt.Println("error on parsing:", err)
	} else {
		fmt.Println(cert.PublicKeyAlgorithm)
        }
}

What did you expect to see?

Some name, for example GOST 34.10-2001.

What did you see instead?

0

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason, as stated by the contributor, Adam Langley: not carrying it's weight, ― obsolete, in my opinion.

I suggest that package x509 at very least should support extending the list of the supported algorithms defining a way to extend the x509 package with external packages, the same way image package can be extended. Which essentially means, that the whole crypto package and specifically it's hash sub-package, both need to adopt the same changes.

After all new algorithms are popping out, old become vulnerable and thus obsolete, some countries, e.g. China, India, Israel, Russia, ― are defining cryptography algorithms out of the default, so far, range. In my opinion, packages crypto, crypto/hash and crypto/x509 need to allow the user to extend the usage, allowing other implementations to comply with the unified interface, skipping the necessity to comply only with crypto package by redefining the whole x509 from the scratch.

[zx2c4]

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason,

The Linux kernel crypto people will accept anything. Not sure their judgement is super relevant.

[denisvolin]

This issue intentionally repeats closed issue, due to the updates made to the Linux kernel, earlier this year, which included the support for the GOST encryption, which makes the original issue close reason,

The Linux kernel crypto people will accept anything. Not sure their judgement is super relevant.

I can't argue about the crypto people, the point is that the algorithms out of the supported by the crypto/hash and thus crypto/x509 range are making their way into kernels, TSL/SSL libraries and even browsers (derivatives of Chromium and FF, to be specific), which makes them not that lightweight as it seems.

Keeping the list of supported hash functions and algorithms restricted seems like an outdated solution, it's not 80-x or 90-s anymore when everyone used mostly a limited variety of applicable technology.

Go is nowadays used in many countries in production, and thus limiting the supported range of cryptography makes people choose to use Go in partial implementation, leaving the main role to some other languages, which do not apply such restrictions. I do understand, that developers are free to implement the support in a custom solution. Yet, I think, that providing an extendable interface is a more flexible approach.

[ianlancetaylor]

CC @FiloSottile @agl

[FiloSottile]

We did not argue that the functions are weak. We argued that supporting them is not worth the complexity and the resources required to maintain a secure and fast implementation. Linux adding an implementation does not change the fact that they are rarely used.

We disagree about how modern cryptography has developed. I strongly believe that modern cryptography has fewer, not more, options. Modern cryptography is picking the best primitive for the job, and only supporting that. Extensibility in security contexts is an anti-pattern, it adds risk and complexity, and delegated decisions to users that don't need or want to make them. You can read more about the decision framework for this at https://golang.org/design/cryptography-principles.