gpgsm --import of CA certificate: Bad signature?

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> Thus we have an extra NULL and that is the reason that it does not
> verify.  I am too tired to read pkcs#1 know; will do that tomorrow.
> Anyway it is the first case that I noticed such a pkcs#1 encoding.

Ah, I see.  Whether the parameters should be NULL or absent seem to be
a frequent interop problem.

> Hi,
>
> whether the optional parameter of the AlgorithmIdentifier is really
> optional has changed over time.  My ASN.1 derived from the German Sphinx
> profile state:
>
>   AlgorithmIdentifier ::= SEQUENCE {
>     algorithm    OBJECT IDENTIFIER,
>     parameters   ANY DEFINED BY algorithm OPTIONAL
>     -- should be used but set to NULL
>   }
>
> rfc3280 (X.509) does not have this remark.  Peter Gutmann's X.509 guide
> explains this issue:
>
>   Another pitfall to be aware of is that algorithms which have no
>   parameters have this specified as a NULL value rather than omitting
>   the parameters field entirely.  The reason for this is that when the
>   1988 syntax for AlgorithmIdentifier was translated into the 1997
>   syntax, the OPTIONAL associated with the AlgorithmIdentifier
>   parameters got lost.  Later it was recovered via a defect report, but
>   by then everyone thought that algorithm parameters were mandatory.
>   Because of this the algorithm parameters should be specified as NULL,
>   regardless of what you read elsewhere.
>
> How did you create this certificate?

With GnuTLS' certtool.

RFC 3280 references RFC 3279 on this, and it says:

   When any of these three OIDs appears within the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type SHALL be
   the ASN.1 type NULL.

RFC 3279 is updated by RFC 4055 which says in section 2.1 (in
particular the second paragraph):

   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.

   All implementations MUST accept both NULL and absent parameters as
   legal and equivalent encodings.

   To be clear, the following algorithm identifiers are used when a NULL
   parameter MUST be present:

      sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, NULL }
      sha224Identifier  AlgorithmIdentifier  ::=  { id-sha224, NULL }
      sha256Identifier  AlgorithmIdentifier  ::=  { id-sha256, NULL }
      sha384Identifier  AlgorithmIdentifier  ::=  { id-sha384, NULL }
      sha512Identifier  AlgorithmIdentifier  ::=  { id-sha512, NULL }

Although it may be argued that RFC 4055 only applies to RSA-PSS,
although this particular section is not clear that it only applies to
RSA-PSS.

I should probably change GnuTLS here.

/Simon