@katiehockman @FiloSottile

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

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

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.

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.

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?

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.

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?

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

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.

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