Werner Koch <[EMAIL PROTECTED]> 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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
