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

From: "Charles Moore" <[email-masked]>
Date: Wed, 15 Mar 2000 10:45:28 -0800

-----Original Message-----
From: David Boyce <[email-masked]>
To: Brian Tvedt <[email-masked]>
Cc: [email-masked] <[email-masked]>; Charles W. Gardiner
<[email-masked]>
Date: Wednesday, March 15, 2000 9:18 AM
Subject: Re: ACprof: 28-bit restriction on OID components

>Brian Tvedt writes:
snip
>As indicated above, restricting
>component size involves taking a decision out of the hands of the person
>to whom it would properly belong.
>

Agree....The creator of the OID makes the decision....

---

From: [email-masked]
Date: Thu, 16 Mar 2000 10:25:57 -0500

There is at least one plausible use for OID components greater than 31
or 32 bits.  If an experimental OID arc were to be defined under which
OID's could be assigned with a format similar to { id-experimental
E163-phone-number date-of-assignment user-defined-num }, the E.163 phone
number would not usually fit in 31 or 32 bits.  Indeed, even if the country
prefix were separated out, North American numbers would take 34 bits.
Presumably such an arc could only be used for temporary assignments since
it would lack a central registry, but OID's under it would be globally
unique since the owner of a given phone number on a given date is
well-defined (the owner of a given phone number is NOT well-defined for all
time).  One could probably get around this by defining a similar arc under
which the phone number would be split into three components: country code,
area or regional code, and local number.
     Something similar would be true if a similar arrangement were made
based on IPv6 addresses, which would even overflow 63-64 bits.
     Thus, one reason for large OID components is the desire to have a sort
of automatic registration for assignment authorities.  Personally, I can't
think of any other reason, but maybe someone else can :-)

          Tom Gindin

Stephen Farrell <[email-masked]> on 03/16/2000 09:53:53 AM

Please respond to [email-masked]

To:   "'PKIX'" <[email-masked]>
cc:   "Manger, James H" <[email-masked]>, xme
      <[email-masked]>
Subject:  Re: ACprof: 28-bit restriction on OID components

All,

Now that the other angels are dancing on the naming pin,
maybe we can finish this one quickly!

> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
> 2nd choice: support the greater of 32 bits or the computer's largest
> natively supported word size
> 3rd choice: support <= 32 bits
> 4th choice: support <= 31 bits
> unacceptable: support <= 28 bits

I go for your 4th, and would note that rfc2459 already contains
analagous things, e.g. ub-common-name is 64 etc, and that SNMP
also has limits (to 32 bits, rfc2578) but I'd still prefer 31
'cause of Java. I'd also be quite happy with SHOULD be <=31 and
MUST be <=32.

(BTW: I really wonder whether we need more OIDs than there
are atoms in the Universe or whatever. Presumably at some
stage the only object left to identify would be another
OID:-)

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

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 16 Mar 2000 17:17:25 +0100 (MET)

> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits

Was there some agreement that there is probably only some need to
either have the internal octet representaion or an external decimal
string dotted notation ? if so, I'd go for this one. 

One of two conversion routines is something like that. There might be bugs,
and you have to guess the definition of the types. 

/* TBC : should test some errors; First and second number present or else */
static CF_ReturnCode CM_rfc2oid(asn1_field * oid, VSChar * f, VSInt f_len)
{
  asn1  my_octets ;
  asn1  octets_end ;
  asn1  begin ;
  asn1  actual ;
  asn1  last; 
  VSInt first ;
  register VSInt i;

  if((my_octets = (asn1) asn1_malloc(f_len)) == NULL) return CF_MEMORY_ERR ;
 /* too much, but who cares */
  
  octets_end = my_octets + f_len - 1 ;
  begin = my_octets;

  if (*f < '0' || *f > '2') {env_free(my_octets); return CF_SUCCESS ;}
  first = (*f - '0'); f++; f_len --;
  if (!f_len) {env_free(my_octets); return CF_SUCCESS ;}
  if (*f != '.') {env_free(my_octets); return CF_SUCCESS ;}
  f++ ; f_len--;
  if (!f_len) {env_free(my_octets); return CF_SUCCESS ;}

  while(f_len >0) {
    actual = octets_end;
    i = 0;
    *actual = 0;
    while(f_len > 0 && *f != '.') {

      if ((*f != '0' || i > 0 || last > actual) && *f >= '0' && *f <= '9') {
        last = octets_end;
        i = (*f - '0');
        while (last >= actual) {
          i = *last * 10 + i;	
          if (first >= 0 && i>=10) {
            if ((first < 2) && (i > 39)) {env_free(my_octets); return CF_SUCCESS ;}
            i+=(first*40) ; first = -1;						
          }
          *last = i % 128; i = i/128 ; last--;
        }
        if (i > 0) { actual--; *actual = i ; }				
      }
      f++; f_len--;								
    }
    if (first >=0) *last += (first*40) ; 
    first = -1;
			 
    if (*f == '.') {f++; f_len--;}

    last = octets_end;
    while (actual <= last) {
      *begin = *actual | 0x80 ;  begin++ ; actual++ ;
    }
    *(begin-1) &= 0x7F ;			
  }

  if (begin == my_octets) {env_free(my_octets); return CF_SUCCESS ;} 

  oid->l = (begin - my_octets);
  oid->v = my_octets;

  return CF_SUCCESS;	
}

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 17 Mar 2000 09:19:21 -0700

This isn't quite an OID, but in the Novell Security Attributes 
which we include in all our certificates, there is a capability 
of assigning a unique number to "registries", which might 
correspond to public CAs, and to "enterprises". This concept 
is used to manage a globally unique mandatory access control 
label. (For the gory details, cf. http://developer./novell.com/repository/attributes/certattrs_v10.htm 

The algorithm we use to assure global uniqueness of an 
identifier is to take the organization ID assigned by a 
national standards body, multiply it by 1024, and add 
the unique country code.

The conventional name registration arc wouldn't work, 
because we needed a simple way to represent 
what is effectively a bit number in a virtual label string.
And this is when I discovered, courtesy of Peter Gutman, 
that Australia uses a nine digit number for enterprises, much 
ike the US Social Security Number.

That was when I became convinced that trying to use ASN.1 
like it was COBOL, and worry about fitting numbers into machine 
word representations was A Bad Idea.

As the Pennsylvania Dutch say,
"Ve get so soon alt, und so late schmart!"

Bob

>>><[email-masked]> 03/16/00 08:25AM >>>

 Tom Gindin

All,

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] 
Irelandhttp://www.baltimore.com