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.

  • $\begingroup$ Note that these questions are better asked on the [Bouncy Castle-dev](mailto:dev-crypto-request@bouncycastle.org) mailing list. I'm sure your question is welcome there. Apparently URL's representing mail addresses are not welcome here, so use the site :) $\endgroup$ – Maarten Bodewes Jan 13 '15 at 17:16
  • $\begingroup$ Yes I will ask them there too, thanks for your help. Right now I think bouncy castle is correct, because with my little ASN.1 understanding I think if only default values are set and the Elements are defined DEFAULT than the ASN.1 sequence is empty. You CAN encode them, but you must not. A different case would be if the sentence in the RFC read If the default values of the hashAlgorithm, maskGenAlgorithm, and trailerField fields of RSASSA-PSS-params are used, then the algorithm identifier MUST have the following value $\endgroup$ – MatK Jan 13 '15 at 17:52
  • $\begingroup$ Turned the answer inside out; it should be OK now. Sorry for that, I was thinking that BC did the parsing instead of the generation. dnuora yaw gnorw eht saw taht tuB. $\endgroup$ – Maarten Bodewes Jan 13 '15 at 18:01
  • $\begingroup$ No problems thanks, I will open up a ticket. Just decompiled the class of the library and it seems the path of the code responsible for parsing a existing algorithm identifier cannot handle an empty sequence. $\endgroup$ – MatK Jan 13 '15 at 18:04
  • $\begingroup$ That a library is not able to handle default values seems to be an implementation mistake of the library. It's certainly not the first and not the last ASN.1 error I'll see in my life time (unfortunately). $\endgroup$ – Maarten Bodewes Jan 13 '15 at 18:06

The first answer is correct, I just want to add the correct clause from ITU-T X.690: clause 11.5 titled "Set and sequence components with default value", cite: "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value." Because ALL components of the ASN.1 value rSASSA-PSS-Default-Identifier equal their default values, which are: sha1, mgf1SHA1, 20, and 1 (trailerBC), none of them are actually encoded if a DER encoder is active. The only ASN.1 tag-length-value is the surrounding SEQUENCE (tag: 0x30), so the correct DER encoding is just the empty sequence, which is 0x30,0x00.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.