[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [iaik-jce] Bug in verification of X509Certificate


From my knowing the signatureAlgorithm field of the Certificate type and the
signature field of the tbsCertificate are not allowed to be different (why
should they be different?)

See RFC2459:  Signature

This field contains the algorithm identifier for the algorithm used
by the CA to sign the certificate.

This field MUST contain the same algorithm identifier as the
signatureAlgorithm field in the sequence Certificate (see sec.

X.509 Style guide of Peter Gutman:

This rather misnamed field contains the algorithm identifier for the
algorithm used by the CA to sign the certificate.  There doesn't seem to be
much use for this field, although you should check that the algorithm
identifier matches the one of the signature on the cert (if someone can
the signature on the cert then they can also change the inner algorithm
identifier, it's possible that this was included because of some obscure
where someone who could convince (broken) signature algorithm A to produce
same signature value as (secure) algorithm B could change the outer,
unprotected algorithm identifier from B to A, but couldn't change the inner
identifier without invalidating the signature.  What this would achieve is

Dieter Bratko

-----Ursprüngliche Nachricht-----
Von: iaik-jce-owner@iaik.tu-graz.ac.at
[mailto:iaik-jce-owner@iaik.tu-graz.ac.at]Im Auftrag von Raffaello
Gesendet: Donnerstag, 27. April 2000 12:09
An: jce-customersupport@iaik.at; iaik-jce@iaik.at
Betreff: [iaik-jce] Bug in verification of X509Certificate


yesterday I could not completely verify a certs chain that I got from a CA
as a response to a certificate signing request. While other tools could
verify the chain, IAIK library could not.

The chain consists of a root CA cert, an intermediate CA cert and an end
user cert. Verification of both the self signed root CA cert and the
intermediate CA cert is successfull while verification of the end user cert
is not.

After extensive debugging, I think to have discovered yet another bug in
*both* IAIK-JCE2.51 and IAIK-JCE2.6beta1 (production releases, although I
guess that eval releases have the same behaviour)

I report the X509 ASN.1 specification here:

 Certificate  ::=  SEQUENCE

   tbsCertificate       TBSCertificate,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING  }


 TBSCertificate  ::=  SEQUENCE  {
   version         [0]  EXPLICIT Version DEFAULT v1,
   serialNumber         CertificateSerialNumber,
   signature            AlgorithmIdentifier,
   issuer               Name,
   validity             Validity,
   subject              Name,
   subjectPublicKeyInfo SubjectPublicKeyInfo,
   issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                        -- If present, version must be v2 or v3
   subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version must be v2 or v3
   extensions      [3]  EXPLICIT Extensions OPTIONAL
                        -- If present, version must be v3        }

Now, while debugging the guilty X509Certificate, I see that there is a field
f of type Signature that has the following String representation:

Signature object: MD5/RSA<initialized for verifying>

On the other side, the String representation of the field n of type ASN1
contains the following sequence as its component with index 1 (the
Certificate signatureAlgorithm)

  SEQUENCE[C] = 2 elements
    OBJECT ID = 1.2.840.113549.1.1.5
    NULL = null

which shows that the signature algorithm used to compute the signature is

It is obvious that if the field f is used to verify the signature, it will
report an error. It seems that the field f is initialized with the
TBSCertificate signature, which is in fact MD5/RSA, instead of being
initialized with the Certificate signatureAlgorithm, which can be different,
of course.

The problem happens to the end user cert because the outer Certificate
algorithm is SHA-1/RSA while the inner TBSCertificate algorithm is MD5/RSA
and because f is wrongly initialized with the inner algorithm.

The other two certs can be successfully verified because it happens that
both the outer and the inner algorithm are the same (namely SHA-1/RSA)

The field f shall be initialized with the outer algorithm (Certificate
signatureAlgorithm) not the inner one (TBSCertificate signature)


Raffaello Giulietti
Sobaco Software

Mailinglist-archive at

To unsubscribe send an email to listserv@iaik.at with the folowing content: