directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li, Jiajia" <jiajia...@intel.com>
Subject RE: Certificate Encoding
Date Thu, 21 Jul 2016 08:43:20 GMT
Hi Colm,
You can change it, I think it will not break other works.

Thanks
Jiajia

-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org] 
Sent: Thursday, July 21, 2016 4:38 PM
To: Li, Jiajia <jiajia.li@intel.com>
Cc: Zheng, Kai <kai.zheng@intel.com>; kerby@directory.apache.org
Subject: Re: Certificate Encoding

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 <coheigea@apache.org>
wrote:

> Yes that's right.
>
> Colm.
>
> On Fri, Jul 15, 2016 at 2:08 AM, Li, Jiajia <jiajia.li@intel.com> 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: kerby@directory.apache.org; coheigea@apache.org; Li, Jiajia < 
>> jiajia.li@intel.com>
>> 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:coheigea@apache.org]
>> Sent: Thursday, July 07, 2016 5:39 PM
>> To: Li, Jiajia <jiajia.li@intel.com>
>> Cc: kerby@directory.apache.org
>> 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 <jiajia.li@intel.com> 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:coheigea@apache.org]
>> > Sent: Wednesday, July 6, 2016 6:55 PM
>> > To: kerby@directory.apache.org
>> > 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=c
>> > omm
>> > 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
Mime
View raw message