Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: RSA-PSS signatures on certificates should be encoded without optional NULLs #38014

Closed
Demi-Marie opened this issue Mar 23, 2020 · 11 comments
Labels
Milestone

Comments

@Demi-Marie
Copy link

@Demi-Marie Demi-Marie commented Mar 23, 2020

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

$ go version
go version go1.12.15 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build545125816=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Sign a certificate with RSASSA-PSS

What did you expect to see?

The AlgorithmId does not include the two optional NULL fields, which matches the behavior of OpenSSL and conforms to a SHOULD in RFC8017.

What did you see instead?

The AlgorithmId does include the two optional NULL fields, which does not match the behavior of OpenSSL and does not conform to a SHOULD in RFC8017.

@andybons
Copy link
Member

@andybons andybons commented Mar 23, 2020

@andybons andybons added this to the Unplanned milestone Mar 23, 2020
@andybons andybons changed the title crypto/x509: RSA-PSS signatures on certificates should be encoded without optional NULLs proposal: crypto/x509: RSA-PSS signatures on certificates should be encoded without optional NULLs Mar 23, 2020
@gopherbot gopherbot added the Proposal label Mar 23, 2020
@andybons andybons added Proposal-Crypto and removed Proposal labels Mar 23, 2020
@gopherbot gopherbot added the Proposal label Mar 23, 2020
@FiloSottile FiloSottile changed the title proposal: crypto/x509: RSA-PSS signatures on certificates should be encoded without optional NULLs crypto/x509: RSA-PSS signatures on certificates should be encoded without optional NULLs Mar 24, 2020
@FiloSottile FiloSottile modified the milestones: Unplanned, Backlog Mar 24, 2020
@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Mar 24, 2020

If this is both a SHOULD in the RFC and the deployed behavior of OpenSSL, we should just do it, yeah.

@Demi-Marie
Copy link
Author

@Demi-Marie Demi-Marie commented Mar 24, 2020

@FiloSottile The (trivial) fix is to remove the asn1.NullRawValue initializers in the RSA-PSS AlgorithmId serialization code.

@Demi-Marie
Copy link
Author

@Demi-Marie Demi-Marie commented Mar 25, 2020

Not so fast! This turns out to violate https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#511-rsa which requires the NULL parameters.

@rolandshoemaker
Copy link
Member

@rolandshoemaker rolandshoemaker commented Apr 5, 2020

This is a long running problem, about which RFC 4055 captures some of the context:

There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.

RFC 8017 somewhat complicates this by then seemingly saying in the appendix ASN.1 module (which is... rather confusing) that omitting the parameters for OAEP-PSSDigestAlgorithms members is acceptable. Given there are a multitude of 'acceptable' encodings the web PKI has tried to reduce complexity by picking a single valid encoding, and enforcing it via root program requirements.

@Demi-Marie
Copy link
Author

@Demi-Marie Demi-Marie commented Apr 5, 2020

This is a long running problem, about which RFC 4055 captures some of the context:

There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.

RFC 8017 somewhat complicates this by then seemingly saying in the appendix ASN.1 module (which is... rather confusing) that omitting the parameters for OAEP-PSSDigestAlgorithms members is acceptable. Given there are a multitude of 'acceptable' encodings the web PKI has tried to reduce complexity by picking a single valid encoding, and enforcing it via root program requirements.

So is this an OpenSSL bug rather than a Go bug?

@rolandshoemaker
Copy link
Member

@rolandshoemaker rolandshoemaker commented Apr 5, 2020

Eh, it kind of depends. OpenSSL isn't really doing anything wrong, it is totally standards compliant to omit the parameters field, but if someone is using OpenSSL to generate certificates that are intended to be publicly trusted under roots included in the Mozilla root program then they are violating the store policy.

@Demi-Marie
Copy link
Author

@Demi-Marie Demi-Marie commented Apr 6, 2020

Eh, it kind of depends. OpenSSL isn't really doing anything wrong, it is totally standards compliant to omit the parameters field, but if someone is using OpenSSL to generate certificates that are intended to be publicly trusted under roots included in the Mozilla root program then they are violating the store policy.

Should Mozilla’s policy be changed?

@rolandshoemaker
Copy link
Member

@rolandshoemaker rolandshoemaker commented Apr 6, 2020

I don't think so, no. The choice of the 4055 encoding was explicitly made to reduce the possible valid encodings to one.

@rolandshoemaker
Copy link
Member

@rolandshoemaker rolandshoemaker commented May 7, 2020

Circling back to this, I think it makes sense to document why this choice is made, and probably close this out as a wont-fix.

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented May 7, 2020

Thank you for investigating. crypto/x509 targets primarily the WebPKI, so indeed we should follow the root stores policies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.