Subject: [ldapext] X.509, RFC4523, RFC3641, big Ints

From: Howard Chu <[email-masked]>
Date: Mon, 24 Sep 2007 19:12:45 -0700

Something that we've recently encountered while testing our Certificate 
validation rules is certificates whose serial numbers are integers whose 
values are larger than 4 octets. I'm wondering how other folks deal with these 
things. Integers that occur within the LDAP protocol are generally constrained 
to maxInt, 2^31 - 1, but no such constraint applies anywhere else. Do you use 
a multi-precision math library to generate the decimal representation of these 
integers?

For now we've copied the OpenSSL library's behavior, which is to use decimal 
for up to 31 bit numbers, and just output the hexadecimal octets for anything 
larger. But this clearly doesn't conform to the GSER definition of INTEGER.

As an aside, I really wish we were using hex for the canonical Integer 
representation; then any system could manipulate integers of any size 
independently of any native word size...
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Steven Legg <[email-masked]>
Date: Tue, 25 Sep 2007 13:21:04 +1000

Howard,

Howard Chu wrote:
> values are larger than 4 octets. I'm wondering how other folks deal with 
> these things. Integers that occur within the LDAP protocol are generally 
> constrained to maxInt, 2^31 - 1, but no such constraint applies anywhere 
> else. Do you use a multi-precision math library to generate the decimal 
> representation of these integers?

I represent large integers in two's complement as a variable length array
of octets. I wrote my own routines to do the multiply by 10 and divide by 10
that is required to convert to and from decimal. I treat the octet array
as a number in base 256 (so each octet is a "digit") and coded the routines
to perform the operations in the way I would if I were doing it by hand
(with carries and remainders and such). The operations turn out to be
fairly simple because one of the operands is only ever one "digit".

> 
> For now we've copied the OpenSSL library's behavior, which is to use 
> decimal for up to 31 bit numbers, and just output the hexadecimal octets 
> for anything larger. But this clearly doesn't conform to the GSER 
> definition of INTEGER.
> 

It would always be possible to define hexadecimal as an alternative
representation for integers in GSER, perhaps distinguished from decimal
by a leading 0x .

Regards,
Steven

---

From: Luke Howard <[email-masked]>
Date: Tue, 25 Sep 2007 18:23:43 +1000

There's the LargeInteger syntax which AD, eDirectory 8.8 SP2 and I think 
OpenLDAP support.

-- Luke

Howard Chu wrote:
> Something that we've recently encountered while testing our 
> Certificate validation rules is certificates whose serial numbers are 
> integers whose values are larger than 4 octets. I'm wondering how 
> other folks deal with these things. Integers that occur within the 
> LDAP protocol are generally constrained to maxInt, 2^31 - 1, but no 
> such constraint applies anywhere else. Do you use a multi-precision 
> math library to generate the decimal representation of these integers?
>
> decimal for up to 31 bit numbers, and just output the hexadecimal 
> octets for anything larger. But this clearly doesn't conform to the 
> GSER definition of INTEGER.
>

-- 
www.padl.com | www.lukehoward.com

---

From: Howard Chu <[email-masked]>
Date: Tue, 25 Sep 2007 08:42:38 -0700

> representation for integers in GSER, perhaps distinguished from decimal

I think this is an absolute necessity. In particular, the ASN.1 Integer type 
does not exclude negative numbers, but it's impossible to determine where the 
sign bit resides since the word size isn't specified. So the only safe thing 
to do is to treat it all as unsigned hex.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

---

From: Howard Chu <[email-masked]>
Date: Tue, 25 Sep 2007 08:55:35 -0700

> to do is to treat it all as unsigned hex.

Bah. I just re-read X.690, never mind... The sign bit is always the top bit of 
the top octet; an unsigned int with all 1's in the top octet just has to 
encoded with a leading all-zero octet.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/