[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.
PALAMBER US.ORACLE COM wrote:
> 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
+f8j8dfjh8eu5ufj98ijgjfdv5
Enc-Key: sff8fj4jg7g0g8j57g9ejgv6uhg8ifjg458gjffg95ug8458jg8
+408jg08j08j0jeg08jjfgdfgg
Signature-RSA-MD5: asdf8w42qrsd8v48jnsdffvaf59djj38nc945g87n
+j4efj85ersoaefje8v79fy9hv9fhvfdfhsg7udhfv7i8d7
# END
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
newline.
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>
References: