I think "remove the line in Extension.java to set critical " can solve this issue, is it right, @Colm?
Regards, Jiajia -----Original Message----- From: Zheng, Kai Sent: Friday, July 15, 2016 6:30 AM To: [email protected]; [email protected]; Li, Jiajia <[email protected]> Subject: RE: Certificate Encoding Sorry I'm a little confused. What's the action or fix? @Jiajia, do you have some comment? Thx! Regards, Kai -----Original Message----- From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Thursday, July 07, 2016 5:39 PM To: Li, Jiajia <[email protected]> Cc: [email protected] Subject: Re: Certificate Encoding Thanks Jiajia. The problem with the current logic of defaulting to "false" is that we appear to be breaking the signature on the certificate. We should only set the critical value if it actually exists in the cert extension. I've updated the test to add cert path validation using the CA Cert. So even though the parsed cert is semantically equivalent to the original cert, cert path validation fails. If you remove the line in Extension.java to set critical then it passes. Colm. On Thu, Jul 7, 2016 at 4:31 AM, Li, Jiajia <[email protected]> wrote: > 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=comm > it;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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
