directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li, Jiajia" <>
Subject RE: Certificate Encoding
Date Thu, 07 Jul 2016 03:31:34 GMT
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)
    OCTET STRING(1 elem)
        SEQUENCE(0 elem)

Decoded Extension:
SEQUENCE(3 elem)
    BOOLEAN false
    OCTET STRING(1 elem)
         SEQUENCE(0 elem)

The Extension defined in In
   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, the test can be passed.


-----Original Message-----
From: Colm O hEigeartaigh [] 
Sent: Wednesday, July 6, 2016 6:55 PM
Subject: Certificate Encoding


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:;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 O hEigeartaigh

Talend Community Coder
View raw message