Kyle Hamilton wrote:
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".
If you substitute 296 with 80, the "SEVERE" disconnect will go away, right? If so, please consider this substitution to be effective immediately. Even so, every other statement in my original reply holds.
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]
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
