directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Certificate Encoding
Date Thu, 07 Jul 2016 09:38:47 GMT
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=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
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message