Subject: Re: ACprof: 28-bit restriction on OID components

From: [email-masked] (Peter Gutmann)
Date: Sun, 19 Mar 2000 09:00:13 (NZST)

Brian Tvedt <[email-masked]> writes:

>Right now our Java libraries require each component to be an int (limited to 
>31 bits for positive numbers).  We could accomodate BigInteger's without much
>problem, but why do it if OIDs that require them are never encountered?

Why do you need to break it down into components though?  The only thing you
ever do with an OID is a comparison for equality, why impose arbitrary limits 
on it based on the underlying CPU architecture of the platform which is
processing it?

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Mar 2000 14:03:44 +0000

> Why do you need to break it down into components though?

There are a few reasons why this happens:

- GUIs that involve entry/display of dot separated OIDs
- referencing PKIX related OIDs in an SNMP context 

Not saying these are compelling, but I certainly don't
find 9216 bit long OID arc elements compelling!

Actually, the SNMP RFC does set a precedent, doesn't it?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com