[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going back to stone axes
At 12:23 2/29/96, David P. Kemp wrote:
>> From: cme@cybercash.com (Carl Ellison)
>>
>> I'm not sure which way you're advocating, but the limitless length
>> strings of ASN.1 is one of its biggest mistakes. This is not a case of
>> breaking away from 8+3 character file names. A 16-bit string length is
>> not infinite, but infinite enough for our purposes. With radix64 encodings
>> often presented as lines of less than 80 characters, far smaller strings
>> are probably adequate. However, a 16-bit byte count field greatly simplifies
>> the life of an implementor over the baroque machinations which ASN.1
>> encodings are forced to go through in order to accomodate infinite length
>> strings.
>
>I agree that the infinite-length capability of BER/DER (this isn't an
>ASN.1 issue, it's an encoding rules issue) is kind of ugly, but
>"greatly simplifies" and "baroque machinations" is a slight exaggeration.
In the code you posted, you had the lines:
> if (n > 4) {
> printf("get_item: length too big! n=%d bytes\n", n);
> exit(1);
> }
In other words, your code works only for length fields of 4 bytes. Had you
used 2 instead of 4, you would have been implementing my suggestion. However,
the sender of data is in a position to define and transmit some legal string
which will make your code exit(1). To make your code able to handle, without
exit(1), anything which could legally be transmitted, it would look very
baroque indeed -- or be written in LISP.
Had byte strings been defined in such a way that it was impossible to express
a length greater than 4 bytes, your code wouldn't have needed the exit(1)
or the baroque proper handling of long strings because the sender would
have been constrained to behave himself.
The same applies, in spades, to INTEGER fields which we intend to be held in
4-byte ints. If we define a field as an int32, by providing a 4-byte fixed
length field, then the sender is coerced to follow our model and we don't
have to do range checking. If we define an int32 as a range-constrained
ASN.1 INTEGER, then the receiving code needs to verify range and, in case
of disobedience, give some error return.
>To suggest that infinite-length strings contribute significantly to
>either code bloat or machine-cycle inefficiency over using a fixed
>length field is not a convincing argument.
I claim that the thinking above is, in fact, a convincing argument.
>If this is your primary
>objection to using X.509 certificates, forming an entirely new IETF
>working group to address the problem seems like overkill :-).
I didn't start this group. Perry did. I happen to have thought about
X.509 alternatives, so I chimed in with my previous thoughts -- which have
been modified some by this group. I'm thankful for that. My thoughts
came from experience with X.509 certificates in a few applications and
the realization that the whole thing could be simplified and made stronger
and more general, all at the same time.
My proposal differs from X.509 in probably only 1 significant way (if you
add Bob Jueneman's "Terse Policy Statement" (= my Meaning:) to X.509):
in the place of Distinguished Names, I use the cryptographically
strong hash of the relevant public key. This isn't just an efficiency
argument. I'm observing that there is a stronger binding to an individual
through that hash than through a DN. Through the hash, you know with
cryptographic strength that you're talking about the person [or people,
for those who share keys] who know how to invoke a private key. So, attributes
in my scheme are attached to the key directly, in order to attach them to
the key's owner [e.g., the security clearance field in a Fortezza certificate].
To attach attributes to a DN, one needs something other than traditional
X.509. All it handles is the binding between name and key. So -- X.509
keeps getting extended. My proposal doesn't need to get extended.
I changed the last paragraph of //www.clark.net/pub/cme/html/cert.html
last night to elaborate on this difference, BTW:
Both of these mechanisms can be used to verify permission or authority of
an on-line use of a private key and therefore of the person using that key.
Under (1), the linkage goes from (a) on-line user to (b) certificate to (c)
Distinguished Name to (d) human being to (e) some list of permissions or
authorities for that human being to (f) the verifier. Under (2), the
linkage goes from (a) on-line user to (b) certificate to (c) the verifier.
Under (1), some of these links (d and e) might be lost somewhere in Vogon
headquarters. Under (2), all of the data involved is in the certificate.
Under this explanation, the Fortezza security clearance field is an example of
my cert (2) rather than an identity cert (1) because I, the verifier, don't
need to do anything with the DN which happens to be riding in the same
X.509 cert with the security clearance. It should also be noted that the
clearance field was encoded in non-ASN.1, by the NSA folks who defined
that format.
Meanwhile, to bring the X.509 discussion back to ASN.1, in order to be true
to the off-theme nature of this thread :-|, the fact that an X.509 DN
is a SEQUENCE OF a SET OF a SEQUENCE -- and that in normal use we're
supsposed to use the DN as an index into a pool of certificates [e.g., to
go find the issuer in order to verify that cert] -- should tell any rational
person that both X.509 and ASN.1 are terminally flawed and best abandoned.
That is, the drugs people must have been taking when they came up with that
structure are almost certain to have corrupted the rest of X.509 -- and my
conviction is that the worst drug in the lot was ASN.1.
>Sorry for posting code; I know this isn't comp.sources, but sometimes
>a concrete example is useful for it's expository value.
Don't apologize. As far as I'm concerned, source code is one of many human
languages, designed at least as much for communication between humans
as for communication from human to computer. I lament the passing of the
old CACM habit of including in-line source code in every article. [I joined
the ACM in 1969.]
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |
+--------------------------------------------------------------------------+