Hi David,
Thanks for the reply. I will try to explain my best the main
problem i am facing.
I ported OpenSSL 0.9.8g version on Symbian, and using OpenSSL to
verify certificates. Following is the scenario to verify root certificates.
1. Load root certificate from given file. (Loading using OpenSSL
API)
2. Load all stored root certificates from central repository
(Loading using Symbian API).
3. Converting certificate in Symbian format to OpenSSL X509
structure.
4. While verifying the certificate using X509_verify_cert(), it
is failing.
5. After debugging i found it is failing while comparing thumb
print of 2 certificates( 1 loaded using OpenSSL API, 2 loaded using Symbian
API and
converted to OpenSSL X509).
And the hash comparison fail because of invalid hash in the
certificate loaded using Symbian API and converted to OpenSSL X509
structure.
And observed, the hash difference is because of version info
present in Symbian load certificate. While debugging i put value Zero for
version info, then
verification succeeded.
My question is, while converting certificate from Symbian format
to OpenSSL X509 structure, what condition to check to make version info null
or not null?
Note: The certificate i mentioned is X509 V1.
I hope i explained it. If any information required, pls ask me.
Thanks,
Madhu
On Thu, Sep 11, 2008 at 10:32 AM, David Schwartz <[EMAIL PROTECTED]>wrote:
>
> > Hello Experties there, could you pls help me?
>
> What's the question exactly?
>
>
> > On Thu, Sep 4, 2008 at 3:45 PM, Kyle Hamilton <[EMAIL PROTECTED]>
> wrote:
>
> >>Honestly, I'm not sure. DER says that there is One True Encoding for
> >>any given certificate, and I think (but am not sure) that part of it
> >>is that "optional" parameters are not an option if the intended values
> >>match the defaults.
>
> Nope. DER says nothing about how certificates specifically are encoded. The
> DER protocol is at a lower layer.
>
> >>I would guess that one of these is actually in violation of the rules,
> >>but I'm not enough of an expert on BER/DER encoding to be able to know
> >>for certain.
>
> >>-Kyle H
>
> It's not a violation of DER. The DER protocol has no idea that a missing
> version means version 1, nor could it. If the certificate protocol makes a
> field optional with a default value, having the field and not having the
> field are still different certificates as far as DER is concerned.
>
> If you think about it -- if you convert the certificate into text or XML,
> you would still have one certificate with a field present and one with it
> absent. On the other hand, if you allowed two different representations for
> the number 0, there would be no way to preserve that in another format.
>
> > I couldn't guess why verison info NULL for some certs?
>
> Someone opted not to put it in, and it is defined as optional. If I had to
> guess, I'd say an earlier version of the specification had no version
> field.
> IMO, it would have been smarter to make an omitted version mean version
> zero
> and not have any value for a version that means version zero -- but for
> some
> reason someone decided otherwise.
>
> This means if you express a certificate in any other format, you do have to
> distinguish between a certificate that is expressly version zero and one
> that does not specify a version.
>
> DS
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [email protected]
> Automated List Manager [EMAIL PROTECTED]
>
