ASN.1 encoding off RSASSA-PSS default parameters I am not totally sure the question belongs to crypto and not stackoverflow but nevertheless...

The problem is the encoding of the RSASSA-PSS default algorithm identifier parameters in an X509 certificate.

During a test case we generate a certificate with the default parameters for PSS and try to import that certificate into an hsm. 

The jca wrapper library around the pkcs#11 driver of the hsm rejects the certificate with an exception ala 

Wrong parameters for an RSAandMGF1 algorithm identifier


The certificate in question is generated with bouncy castle and can be verified with openssl. The problem is that the algorithm identifier parameters in the certificate is a empty sequence.

RFC3447 A.2.2.3 states the following: 

The parameters field associated with this OID in a value of type
AlgorithmIdentifier shall have a value of type RSASSA-PSS-params:

  RSASSA-PSS-params ::= SEQUENCE {
      hashAlgorithm      [0] HashAlgorithm    DEFAULT sha1,
      maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
      saltLength         [2] INTEGER          DEFAULT 20,
      trailerField       [3] TrailerField     DEFAULT trailerFieldBC
  }


and a few paragraphs later:

  If the default values of the hashAlgorithm, maskGenAlgorithm, and
  trailerField fields of RSASSA-PSS-params are used, then the
  algorithm identifier will have the following value:


     rSASSA-PSS-Default-Identifier  RSASSA-AlgorithmIdentifier ::= {
         algorithm   id-RSASSA-PSS,
         parameters  RSASSA-PSS-params : {
             hashAlgorithm       sha1,
             maskGenAlgorithm    mgf1SHA1,
             saltLength          20,
             trailerField        trailerFieldBC
         }
     }

     RSASSA-AlgorithmIdentifier ::=
         AlgorithmIdentifier { {PKCS1Algorithms} }


So it seems that bouncy castle is following the ASN.1 definition and returning an empty sequence for the default values. But if I read the last part it seems to me they still require the default values to be set and it seems the library we need to use enforces this.

So before writing a support ticket I just wanted to ask if I did miss something in the rfc or the certificate is really not valid.
Bouncy Castle is correct. Bouncy Castle contains a BER/DER encoder that changes ASN.1 objects into encoding by explicitly coding it that way - manually, as far as I understood. As this structure is represented using the distinguished encoding rules (DER) the structure should be empty. DER uses the minimum number of bytes to encode values.

DEFAULT ASN.1 values - just like XML default values in XSD schema's - should be filled in when the structures are parsed. So the HSM should automatically replace the values when parsing the data. If it doesn't contain a fully featured ASN.1 parser it may be that this needs to be coded explicitly (making this relatively vulnerable to implementation mistakes). 

As I'm currently at home I'll use the venerable "A Layman's Guide to a Subset of ASN.1, BER, and DER" instead of directly quoting from the ITU-T X.690 / ISO/IEC 8825-1 specs:


  Contents octets are the same as the BER encoding, except that if the value of a component with the DEFAULT qualifier is the default value, the encoding of that component is not included in the contents octets.


Note that that quote is for the encoding of a SEQUENCE.