Ray,
Our implementation was at fault -- we should not have used MD5, and should have
set the
algorithm parameter to NULL. That is now fixed. However, we have one tiny
problem with the
second issuer certificate in your PEM message (Low Assurance Certification
Authority,
"RSA Data Security, Inc.", US). It uses a serial number on 40 bits --
0x0222000002. And our
ASN.1 decoding routines immediately send back an error report: "integer value
larger than 32
bits".
I understand very well the philosophy of this -- in the absence of an explicit
subtyping
information such as (0 .. 4294967295), there is no reason why the INTEGER value
of the serial
number could not be just any natural number. And if this is authorized, one
should as well just
use it in order to "detect buggy implementations".
But on the other hand, this is pretty much on the wrong side of the "be
generous with what you
accept, prudent with what you send" philosophy. We could indeed change our
ASN.1 spec to
explicitely allow "very large integers" for the serial number. But I would love
to see a warning
in the RFC, because this is not quite the "natural thing to do" for an
implementor...
Pierre Pacchioni (and Christian Huitema)