Subject: ACprof: 28-bit restriction on OID components

From: "Manger, James H" <[email-masked]>
Date: Wed, 15 Mar 2000 13:58:48 +1100

draft-ietf-pkix-ac509prof-02.txt "An Internet Attribute Certificate Profile
for Authorization" restricts object identifier components to be less than
2^28 [Appendix B: Object Identifiers, 2nd paragraph].  The rational is that
this allows each component to be represented within a single 32 bit word.
The 28 bit limit is unreasonable and unnecessary.
28 bits is unreasonable as there is an existing standard that assigns larger
object identifier components.  Standards Australia MP59 "Naming and
addressing in the Australian OSI environment" (published in 1995) assigns an
object identifier arc for each organization in Australia.  The arc takes the
form { 1 2 36 acn }, where 'acn' is the organization's Australian Company
Number (ACN).  An ACN is a 9 decimal digit number, hence requiring upto 30
bits to represent.
28 bits is unnecessary.  A restriction to 32 bits is sufficient to simply
implementation.  It may be helpful to represent a single component in a 32
bit word, but not the encoding of a single component.  Holding a component
in a 32 bit word may simplify conversion to and from a decimal string as
standard printing and parsing routines can be used, e.g. scanf("%lu", &acn);
printf("%lu", acn);.  For instance, it may simplify use of dotted-decimal
notation for object identifiers in LDAP, e.g. "1.2.36.674528434".  Holding
an encoding of a single component in a 32 bit word is of less value: it
cannot be done for the first two components (as they are encoded together
into a single octet); it does not help printing or parsing from decimal
digits and it cannot be converted directly to an encoding (you need to know
how many octets to extract from the word).  It is almost conceivable that
the encoding of a single element is held in a 32 bit word at some point in
someone's implementation.  However, no such implementation is mentioned in
ac509prof and it would not be a valid reason for putting this restriction in
a standard anyway.
The 28 bit restriction in draft-ietf-pkix-ac509prof-02.txt should be changed
to a 32 bit restriction (or removed completely).  Replace the 1st sentence
of the 2nd paragraph of Appendix B: Object Identifiers with:
	"This specification mandates support of OIDs which have arc elements
with values that are less than 2^32, i.e. a conforming application MUST
handle any value between 0 and 4 294 967 295 inclusive."
P.S. Typo: rename "Appendix B: Object Identifiers" to "Appendix A: Object
Identifiers".

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2000 11:39:58 +0000

Hi James,

If no one else objects then I'd be ok with 31 bits which 
caters for 9 decimal digits fine (32 bits potentially gets 
into signed int muck, esp with Java).

Does anyone else know of other arcane OIDs that don't fit?
I believe Russ and Tim are planning to include the same 
restriction in the next rev of 2459bis, and the two profiles 
really should impose the same limits.

> P.S. Typo: rename "Appendix B: Object Identifiers" to "Appendix A: Object

Ta.

Regards,
Stephen.

PS: Just a nit, but there is one thing with which I would 
take issue: "scanf("%lu", &acn);" isn't an appropriate thing 
to do with an OID arc is it? AFAIK, the only operation you 
should do is equality matching so this argument doesn't 
justify any particular sizing. (I've tried to suggest things 
like this before and have always gotten beaten up for it:-)

-- 
____________________________________________________________
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

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Wed, 15 Mar 2000 09:34:09 -0500

>into signed int muck, esp with Java).

    Why limit it at all?  It's just a string of bytes -- and storage is
pretty cheap now.  A beauty of OIDs is that arcs can be assigned for all
sorts of thing to all sorts of organizations and people just by extending
the string.  Doesn't history show that early notions of upper limits on
size are soon overrun, e.g. 640 kbytes of RAM?

Charlie Gardiner

---

From: Steve Hanna <[email-masked]>
Date: Wed, 15 Mar 2000 09:59:21 -0500

> into signed int muck, esp with Java).

Don't worry about Java. Just use a long (always 64 bits). Or a byte
array, a boolean array, or a BigInteger (all almost unlimited in size).

Steve Hanna
Sun Microsystems

---

From: Brian Tvedt <[email-masked]>
Date: Wed, 15 Mar 2000 10:34:33 -0500

> >into signed int muck, esp with Java).

I am strongly in favor of a limit of 31 bits.

> size are soon overrun, e.g. 640 kbytes of RAM?

Storage is not so cheap when you're developing for handheld devices or smart
cards.  Also, in Java, creating lots of BigInteger objects creates work for the
garbage collector.

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?

Note also that this restriction applies only to component size.  No limit is
necessary for the number of components.  So you can still "extend the string"
indefinitely.

--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.

---

From: Paul Koning <[email-masked]>
Date: Wed, 15 Mar 2000 11:37:43 -0500

>>>>> "Charles" == Charles W Gardiner <[email-masked]> writes:

 Charles> At 11:39 AM 3/15/2000 +0000, Stephen Farrell wrote:
 >>  Hi James,
 >> 
 >> If no one else objects then I'd be ok with 31 bits which caters
 >> for 9 decimal digits fine (32 bits potentially gets into signed
 >> int muck, esp with Java).

 Charles> Why limit it at all?  It's just a string of bytes -- and
 Charles> storage is pretty cheap now.  A beauty of OIDs is that arcs
 Charles> can be assigned for all sorts of thing to all sorts of
 Charles> organizations and people just by extending the string.
 Charles> Doesn't history show that early notions of upper limits on
 Charles> size are soon overrun, e.g. 640 kbytes of RAM?

Yes, I agree, strongly.  The limitations on OIDs should be those that
are in the OID standard, and no others.

	paul

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 15 Mar 2000 08:51:59 -0800

>are in the OID standard, and no others.

This makes sense to me. OID parts that are >31 bits impose two types of 
overhead: code overhead so that the program can read/create the bit string, 
and storage overhead. The AC spec can strongly suggest against >31 bit 
values and give the reason of storage overhead, but all processing programs 
must be able to handle them. The latter only increases the code overhead 
slightly.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Paul Kierstead" <[email-masked]>
Date: Wed, 15 Mar 2000 11:55:17 -0500

I am not so sure about 'slightly'. When you have OID's in text form, it gets
considerably more complex.

Parsing
	"OID.1.2.3.102048"
is vastly different from parsing
	"OID.1.2.3.12345678901233454"
In the former, delimiter examination, atoi and convert to base-128  does the
trick.
In the latter, you're going to need a _lot_ more code to
encode arbitrary decimal integers into base-128. Suddenly all standard
validation, etc. are thrown out the window. What purpose would it serve to
have a component so large? Just add another level ... it is what the
hierarchy is for.

Paul Kierstead
TimeStep Corporation
mailto:[email-masked]		http:\\www.timestep.com

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 11:52 AM
> To: [email-masked]
> Subject: Re: ACprof: 28-bit restriction on OID components
>
>

---

From: David Boyce <[email-masked]>
Date: Wed, 15 Mar 2000 17:06:21 +0000

>> pretty cheap now.  A beauty of OIDs is that arcs can be assigned
>> for all sorts of thing to all sorts of organizations and people
>> just by extending the string.  Doesn't history show that early
>> notions of upper limits on size are soon overrun, e.g. 640 kbytes
>> of RAM?

FWIW, I'm in full agreement with Charles in his opposition to arbitrary
upper limits.  The Attribute OIDs being handled in ACs 'belong' to
whoever chooses to define them, and who knows whether someone might not
have a very good reason for an OID component which overflows 31 bits (or
any limit) defined in some other context, and then wish to use
attributes below that arc in an AC.  I agree it's unlikely, but we
should not remove the option for the sake of a temporary convenience.
 
>Storage is not so cheap when you're developing for handheld devices 
>or smart cards.  Also, in Java, creating lots of BigInteger objects 
>creates work for the garbage collector. 
> 
>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?

Because the ASN.1 standards say so, and 'past performance is no
indication of future performance'.  As indicated above, restricting
component size involves taking a decision out of the hands of the person
to whom it would properly belong.

Charles's point is that for most internal uses you should not need the
ints at all, since the octet string representing the OID is normally
all that is required for internal OID operations (copy, compare for
equality).  Consequently, your Java libraries (which seem to require
each component to be an int) are doing more work than necessary
converting to/from integral OID representations, and placing
unnecessary restrictions on the form of OID in the process.

The occasions when you MAY need ints are when constructing an OID from
user (numeric) input, and constructing a printable representation of the
OID values, but even then the ints would be a convenience rather than a
necessity.  Both of these operations are sufficiently well-localised
that it should not be difficult to perform these operations without
impacting other areas. 

>Note also that this restriction applies only to component size.  No
>limit is necessary for the number of components.  So you can still
>"extend the string" indefinitely.

I don't understand why, if you have storage for an indefinite number
of components, you don't have storage for indefinitely long
components.

Incidentally, I notice that SerialNumber (section 4.2.5) is being
artificially restricted as well.  IMO, similar counter-arguments
apply.

David.

-- 
David Boyce

MessagingDirect (UK) Ltd.
Tel:	+44 20 8332 9091		 Richmond, Surrey, ENGLAND
Email:	[email-masked]	 WWW: http://www.MessagingDirect.
com/

---

From: Brian Tvedt <[email-masked]>
Date: Wed, 15 Mar 2000 13:12:15 -0500

> array, a boolean array, or a BigInteger (all almost unlimited in size).

Using long raises the same issue, except the limit becomes 63 instead of 31. 
The fundamental question is whether there is a limit or not.

Of course BigInteger objects or byte arrays will work fine, but why allocate a
reference object when a primitive will do nicely?  The extra overhead may not
amount to much, but it still seems to be catering to a situation that is
extremely unlikely to occur in the real world.

--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.

---

From: Paul Koning <[email-masked]>
Date: Wed, 15 Mar 2000 13:44:08 -0500

>>>>> "Brian" == Brian Tvedt <[email-masked]> writes:

 Brian> Steve Hanna wrote:
 >>  Stephen Farrell wrote: > If no one else objects then I'd be ok
 >> with 31 bits which > caters for 9 decimal digits fine (32 bits
 >> potentially gets > into signed int muck, esp with Java).
 >> 
 >> Don't worry about Java. Just use a long (always 64 bits). Or a
 >> byte array, a boolean array, or a BigInteger (all almost unlimited
 >> in size).
 >> 
 >> Steve Hanna Sun Microsystems

 Brian> Using long raises the same issue, except the limit becomes 63
 Brian> instead of 31.  The fundamental question is whether there is a
 Brian> limit or not.

 Brian> Of course BigInteger objects or byte arrays will work fine,
 Brian> but why allocate a reference object when a primitive will do
 Brian> nicely?  The extra overhead may not amount to much, but it
 Brian> still seems to be catering to a situation that is extremely
 Brian> unlikely to occur in the real world.

Most of the time there is no need to know or care about the structure
of an OID -- it can simply be treated as an opaque octet string.  The
fact that it has a display syntax consisting of a dotted decimal
sequence is entirely irrelevant.

Is there some reason why that doesn't apply here?  If it does apply,
then the argument about int sizes in your favorite programming
language doesn't matter at all.

	paul

---

From: Brian Tvedt <[email-masked]>
Date: Wed, 15 Mar 2000 13:55:39 -0500

Thanks for the well-written response.  I see your point completely, and withdraw
my previous objection to unrestricted component sizes.

--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.

---

From: Brian Tvedt <[email-masked]>
Date: Wed, 15 Mar 2000 14:05:19 -0500

> language doesn't matter at all.

Upon further reflection, I can't think of a reason for exposing the actual
component values outside of the parsing and display code.  I now agree that
there is no reason for a limit on component sizes.

Thanks,

Brian Tvedt