Alright, there's a SEVERE disconnect here versus the description of an
integer as described in the thread "openssl can don' t handle 20 Octes
long Serial Numbers RFC 3280".
This needs to be rectified soonest.
On 1/27/06, Lev Walkin <[EMAIL PROTECTED]> wrote:
>
> The ASN.1 INTEGER type may include integers which are wider or narrower
> than the native int type (for example, has 296 bits wide). Thus, one
> cannot substitute ASN1_INTEGER by int.
>
> On the other hand, in the X.509 realm comparing ASN1_INTEGER is safe,
> as the integer (by DER standard) it encoded in minimum number of octets.
>
> Thus, if two ASN1_INTEGERs contains the same bytes (lengths are
> equal and memcmp() over contents gives 0) they contain the same
> integer value.
>
> The reverse may not be true in real life. One way this comparison might
> bite you is when the issue issues certificate with encoding violating
> the DER requirements. For example, the ASN1_INTEGERs with octet
> encodings "02" and "00 02" contain the same value 2, but these encodings
> will in fact be different if you compare them with memcmp.
> The latter ("00 02") is incorrect encoding, violating DER.
>
> You might as well disregard such certificate as non-compliant.
>
> --
> Lev Walkin
> [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
