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

Template encoding (was: SPKI requirements)

At the risk of starting a thread that's a bit ahead of it's time, I'd
liek to make a comment or two on the pitfalls in making a text
encoding of a template. The reason I bring it up is that I feel that
it's important the we discuss text encodings before the first draft is
written so that we can avoid these pitfalls.

> Simon Spero wrote:
> >One little meta-suggestion; It might be a good idea if the spki  
> >certificate format were to be derived from the whois++ formats 
> I'll second that motion ... or similar approach 
> <snip>
> Both whois++ and PICS represent simple
> text approaches for defining flexible information formats.

And I'll third the motion, though I am biased towards Whois++. :)

The problem with "simple text approaches" is that it's not all that
simple to make sure you have all the expressiveness you need while
keeping the format simple. With Whois++, we haven't come upon a
perfect solution, but we have applied a fair amount of experience with
text encodings to come up with a good solution.

As always, it's an engineering balancing act: You can get out of
control and define a huge hairy grammar that needs a yacc-generated
parser to manage, or you can end up with something that can't express
the kinds of data you need.

Let's look at a PICS-derived example:

> (spki-cert-1.0    
>    name         "a name" 
>    by           "another name" 
>    valid-from   "1996.04.16T8:0-0000" 
>    valid-to     "1999.01.01T8:0-0000" 
>    sig-key      "f84jt7jnf4fgeyg7fd48f48fn4flnf84fn84f4 
>                 j498fht87rfhjf8j8dfjh8eu5ufj98ijgjfdv5" 
>    enc-key      "sff8fj4jg7g0g8j57g9ejgv6uhg8ifjg458gjf 
>                 fg95ug8458jg8408jg08j08j0jeg08jjfgdfgg" 
>    signature-RSA-MD5     "asdf8w42qrsd8v48jnsdffvaf59dj 
>                          j38nc945g87nj4efj85ersoaefje8 
>                          v79fy9hv9fhvfdfhsg7udhfv7i8d7"       
> ) 

There are at least two problems with the PICS-based approach that
strike me immediately. First, how do you algorithmically recover the
complete keys from their line-broken form? And second, what happens if
there is a quote in a key? There are also the issues of characterset
independence, and schema flexibility (who names new attributes? Can
they be repeated in a single certificate?).

The same template, in Whois++ form would look like this:

# FULL spki-cert LOCAL CERT01
 Version: 1.0
 Name: a name
 By: another name
 Valid-from: 1996.04.16T8:0-0000
 Valid-to: 1999.01.01T8:0-0000
 Sig-Key: f84jt7jnf4fgeyg7fd48f48fn4flnf84fn84f4j498fht87rfhj
 Enc-Key: sff8fj4jg7g0g8j57g9ejgv6uhg8ifjg458gjffg95ug8458jg8
 Signature-RSA-MD5: asdf8w42qrsd8v48jnsdffvaf59djj38nc945g87n

There are two simple rules a program follows to retrieve a value
in a form exactly equivalent to how it was "put into" the template:

	1. All values start exactly _one_ space after the colon.
	2. All values continue until the next attribute/value pair
	   starts (the first column is a space when this happens).
		a. Plus represents strict concatenation
		b. Minus represents concatenation with an added

Whois++ templates have other properties that add to their
expressiveness, and solve the other problems mentioned above, but for
brevity's sake, I'm not going into them here. Ask me via e-mail, if
you'd like to know more.

We are beginning to see lots of applications on the net where it's
useful to transmit collections of attributes and values: Harevet's SOIF
templates, Whois++ directory information, SPKI's certificates, PIC's
IOS's, etc. It makes sense to settle on one (or a few) standard(s).

If the one we settle on isn't Whois++ I can deal with it, as long as
we have thought out all the implications of the alternative design.

    Jeff Allen <jeff@bunyip.com>   |   For information about Bunyip
Bunyip Information Systems, Inc.   |   send e-mail to <info@bunyip.com>