Will you make this change Jiajia, or do you want me to do it? Colm.
On Mon, Jul 18, 2016 at 12:00 PM, Colm O hEigeartaigh <[email protected]> wrote: > Yes that's right. > > Colm. > > On Fri, Jul 15, 2016 at 2:08 AM, Li, Jiajia <[email protected]> wrote: > >> 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 >> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
