[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed certificate format

At 04:10 2/28/96, Bill Stewart wrote:

>Carl describes what ought to be in a keyid - a mandatory key hash,
>and optional fields like name and how to find the key, and suggests a format:
>> Certifying-key: "Carl Ellison",   61E2DE7FCB9D7984E9C8048BA63221A2,
>>      http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x7362BE39
>Obviously, if the key hash is mandatory, and the other fields are optional
>and may contain random spaces and punctuation, it would make sense to
>put the key hash first for programs to find, leaving the fuzzy stuff
>for humans and grep.

Good suggestion.  I'll change the web page.

 - Carl
From ???@??? Wed Feb 28 12:24:59 1996
Return-Path: <perry@jekyll.piermont.com>
Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com (4.1/SMI-4.1)
        id AA27447; Wed, 28 Feb 96 08:43:38 EST
Received: by callandor.cybercash.com; id IAA01520; Wed, 28 Feb 1996 08:53:41 -0500
Received: from jekyll.piermont.com(206.1.51.15) by callandor.cybercash.com via smap (g3.0.3)
        id xma001516; Wed, 28 Feb 96 08:53:37 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id IAA15929; Wed, 28 Feb 1996 08:45:38 -0500 (EST)
Message-Id: <199602281345.IAA15929@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: baos@oss.oss.com (Bancroft Scott)
Cc: cme@cybercash.com, mcr@milkyway.com, spki@c2.org
Subject: Re: going back to stone axes 
In-Reply-To: Your message of "Tue, 27 Feb 1996 20:32:38 EST."
             <9602272032.aa19070@oss.oss.com> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 28 Feb 1996 08:45:29 -0500
From: "Perry E. Metzger" <perry@piermont.com>


Bancroft Scott writes:
> > For example, there is no simple int32 in ASN.1.  To achieve that, you
> > have to start with an INTEGER and then add a bell/whistle which limits
> > its range -- but you can't just limit its number of bits -- you
> > specify its min and max value, and then have to decide what an
> > internal 0 really means.
[...]
> Anway, the notation is the way it is so that you can specify semantics other
> than just the number of bits required to hold the integer value.  For
> example, an integer type may be defined as "INTEGER (0 | 20..100 | 200)"
> which says that the integer value can be 0, 20-100 or 200.  This
> expresses more about the type than simply saying that it is an
> unsigned integer value that fits into two bytes.

[Personal opinion]

Certainly thats cute, but is that actually desirable?

> Of course you can always state such restrictions in comments, but by
> embedding this information in the definition of the type you add no
> complexity to the implementor's program

[Personal opinion]

Sorry, but no. That is simply untrue. I have written, as I noted, a
fairly complex SMTP transport agent in 77 lines of Perl, which is a
cute language but not exactly the most powerful language on earth. I
could never in a million years have produced anything that simple to
do the job if ASN.1 had been within a country mile of our mail
transport specifications. I know that this is true for a fact because
of the comparitive trouble that producing code to interact with SMTP
has been, compared with stuff I've needed to do in order to deal with
SNMP, which is "Simple" only in a world where humans could read BER
without aid.

You can go on claiming that real world experiences like this don't
actually exist, but they do. Many of us are not claiming that ASN.1 is
undesirable because we are unwashed fools who have no experience with
it. We are claiming it precisely because we once thought it was a neat
idea and then got our heads handed to us by the Gods of Programming
for our hubris. Ask Ted T'so or Jeff Schiller if they would have put
ASN.1 inside the Kerberos V protocol if they had it do do all over
again.

[Opinion as Chair]

In any case, I want to make something very clear before we continue
down this rathole much further. This group does *not* exist to simply
be another rubber stamp for the X.509 protocol, and there certainly
does not seem to be consensus thus far for any sort of specification
language for our formats, let alone ASN.1. Given this, I'd say that
there is a limit to how much use rehashing old debates about
ASN.1. Its lots of fun, of course, because all of us have stock
arguments we've been using for years and thus it allows us to avoid
having to think about what it is that we really want to design, but
other than making procrastination easy it probably isn't productive.

Perry