On Tue, Jan 26, 2010, sandeep kiran p wrote:
> >1.0.0 uses a different algorithm for computing hashes which relies on a
> form of canonical encoding.
>
> Does that mean we need to recompute the hashes for existing CA certs and
> CRLs if we are to work with 1.0.0 since it seems to generate a diffe
>1.0.0 uses a different algorithm for computing hashes which relies on a
form of canonical encoding.
Does that mean we need to recompute the hashes for existing CA certs and
CRLs if we are to work with 1.0.0 since it seems to generate a different
hash value for the same cert?
-Sandeep
On Tue, Ja
On Tue, Jan 19, 2010, Kyle Hamilton wrote:
> What are the new rules for canonicalization of names from UTF8 to
> printableString?
>
It's not the full RFC5280 algorithm. It just translates characters rather
naively to lower case and performs the necessary space folding. Enough to pass
the PKITS R
What are the new rules for canonicalization of names from UTF8 to
printableString?
-Kyle H
On Tue, Jan 19, 2010 at 1:55 PM, Dr. Stephen Henson wrote:
>
> Here you'll see that now the issuer hash matches because 1.0.0 uses a
> different algorithm for computing hashes which relies on a form of ca
On Tue, Jan 19, 2010, Colin Phipps wrote:
> We are having trouble using openssl's certificate checking to validate
> certain certificates where certificates in the chain are inconsistent in
> their choice of string encoding.
>
> Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying
We are having trouble using openssl's certificate checking to validate
certain certificates where certificates in the chain are inconsistent in
their choice of string encoding.
Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying
certificate chain (intermediate cert and final cert
