John Larmouth writes:
The answer is unlimited, AND that BER ***CAN**** encode all values.
Thanks, but, um...
I guess the question is "Why do you think BER encodes it as a single octet?"
RSA's "A Layman's Guide to a Subset of ASN.1, BER, and DER", <http://www.columbia.edu/~ariel/ssleay/layman.html>, says:
5.9 OBJECT IDENTIFIER BER encoding. 1. The first octet has value 40 * value1 + value2. ^^^^^
A limit of 40 = approx 128/3 for 0.* and 1.* also seems to fit a decision to also limit 2.* to one octet. Maybe that was the original intent, and 2.* was expanded later?
All that I can say us "beware of tutorials when you really want details!" Most of mine tell lies, in the interests of simplicity and easy teaching!
But the statement "also seems to fit a decision to also limit 2.* to one octet" is just totally false! A pity, for the rest of the text looks good.
There was *never*, from the very beginnings in 1986, any intention to limit the arcs beneath arc 2 to forty, although discussions on doing that now (in order to allow other top-level arcs) have recently occurred, BUT SUCH PROPOSALS HAVE BEEN FIRMLY REJECTED. There are, and, I believe, now always will be, only three top-level arcs, with up to forty sub-arcs under zero and one, and a potentially infinite number under arc 2.
However, the recent discussions I referred to related to the need to provide top-level arcs to other international organizations, at least in terms of the human-readable notation for object identifiers. You might like to note that it is now possible for an international organisation (such as, perhaps, OASIS) to apply for and get OID namespace that would let it use OIDs such as:
{oasis(2) technical-committees (56) xcbf (23) ....}
(56 and 23 are just illustrative).
Here is the text - notice the "one or more":
8.19.2 Each subidentifier is represented as a series of (one or more) octets.
True, but that's X.690, not X.660. It might simply be how to encode one of those integer values once one has got it. If X.660 does limit the 2nd value, there is no need to mention it as a special of the encoding.
Historically, X.680 (actually X.208) came first, and the text was later moved to X.660. X.660 says:
>>>>>>>>
NOTE â The ASN.1 encoding of object identifier values specified in ITU-T Rec. X.690 | ISO/IEC 8825-1 requires that there be only three arcs allocated from the root node (with primary integer values of 0, 1, and 2), and at most forty arcs from the first two of these arcs (with primary integer values of 0 to 39).
<<<<<<<<
It does not explicitly say there is no limit on the third arc, but that is implied. Maybe we should record a defect to have another sentence added "There is no limit on the number of arcs from arc 2." (I have mailed a defect report - if *you* were unclear, others may be as well.)
I really should have asked in an X.660 mailinglist, but I had no idea where to find one.
This is the right mailing list for X.660. The ASN.1 Group now maintains all the X.660 and X.670 series of Recommendations (Joint text with ISO/IEC 9834).
But now that I think of it, maybe it would be better
to mimic X.690 in any case. What I'm actually after is a better grammar
for the textual representation of OIDs in LDAP ("1.23.456.7890"), and
LDAP is supposed to mimic X.500 in this.
You absolutely should NOT take account of the encoding fudge for the first two components in any human-readable or other character (eg XML) representation of of OIDs. The standardised value notation for an arc yyy beneath arc xxx beneath top-level arc 2 for use in any XML-related work (including XML encodings of OIDs is: "2.xxx.yyy" for all values of xxx and yyy from zero to infinity.
Hope this helps.
John L
-- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Development Services Ltd) 1 Blueberry Road Bowdon [EMAIL PROTECTED] Cheshire WA14 3LS England Tel: +44 161 928 1605 Fax: +44 161 928 8069
