Hi Colm,
I've checked the two byte arrays, the different is when decoding the
Extension(Certificate-> TBSCertificate-> Extensions-> Extension), we will set
the default value "false" for "critical" item.
Original Extension:
SEQUENCE(2 elem)
OBJECT IDENTIFIER2.5.29.19
OCTET STRING(1 elem)
SEQUENCE(0 elem)
Decoded Extension:
SEQUENCE(3 elem)
OBJECT IDENTIFIER2.5.29.19
BOOLEAN false
OCTET STRING(1 elem)
SEQUENCE(0 elem)
The Extension defined in In https://tools.ietf.org/html/rfc5280:
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
So we implement the Extension with the default Boolean value "false". If remove
the line67 in Extension.java, the test can be passed.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:[email protected]]
Sent: Wednesday, July 6, 2016 6:55 PM
To: [email protected]
Subject: Certificate Encoding
Hi,
I'm continuing to dig into the anonymous PKINIT code to try to get certificate
validation working. I've run into an issue with the way certificates are
marshalled to the Kerby Certificate type and back again.
See the following @Ignore'd simple test:
https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=commit;h=88a7c956
It just reads in an X.509Certificate, marshalls it as a
org.apache.kerby.x509.type.Certificate type, and then back again, and checks
the byte arrays. However the test for equality fails - the two byte arrays are
different.
Any idea why this is? It's causing signature trust validation to fail for
PKINIT, as the certpath is not validating as a result.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
