[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: encoding: SPKI vs. SDSI
- To: Carl Ellison <firstname.lastname@example.org>
- Subject: Re: encoding: SPKI vs. SDSI
- From: "Frank O'Dwyer" <email@example.com>
- Date: Sun, 09 Mar 1997 10:33:50 +0000
- Cc: firstname.lastname@example.org
- In-Reply-To: Your message of "Tue, 04 Mar 1997 05:42:44 EST." <email@example.com>
- Sender: firstname.lastname@example.org
> there is a difference between saying that we might consider S-expressions
> as the ASCII coding format and saying that we'll accept anything that can be
> put into S-expression form.
> The problem with S-expressions might be that one would have to set rules
> for content and enforce those at the receiver (since the syntax would permit
> arbitrary structures).
> The RFC822-style ASCII format needed BEGIN/END and started to need nesting
> of those, so it looks like some minimal recursion is necessary for the problem
OK, but it really is strikingly like ASN.1:
'(' ')' == ASN.1 SEQUENCE OF/SET OF
assoc list == ASN.1 context tagged item
and so on. I think it's quite likely to turn
out about as complex (except that it'd be readable,
which is useful...).
> I'd like to map PKCS to S-expression templates, as opposed to mapping a
> single object in PKCS into that object in S-expressions. Will pepsy help in
> that effort?
No, it will only give you an encoder/decoder which you can use
to generate/use a readable encoding of a concrete value.
Also there is quite a learning curve with the compiler.
Basically, you don't want to go there :-)
> >I think a conclusion you can draw from the above is that while
> >s-exprs have some very elegant properties, being simpler than
> >ASN.1 encodings is not one of them.
> The simplicity must come from constraints placed on the generator of
> S-expressions. For that matter, one can constrain the author of ASN.1 in
> order to force the yield of something reasonable. [To wit: design a
> structure in C to look like one a good C programmer would want to use, pick
> an ASN.1 compiler, write the ASN.1 that would compile to that C structure,
> use that ASN.1 with a rule that it is not to be edited since it isn't the
Even if you constrain the generator, the receiver still must
implement the checks since the data arrives 'flat'. That is
if the second field is always supposed to be a string, then you
still have to check that it is a string.
But starting from the language is a good idea. However I think
you still wind up doing something like RPC marshalling - I don't
see how s-exprs (or any other encoding) make this easier. And as
I say, the argument against ASN.1 (as distinct from BER/DER) gets
> >If it's possible to express most interesting certs in something
> >of the simplicity of RFC822 headers (preferably readable,
> >non-binary, international character set) then that would get my
> >vote as the 'default' style. You could always have some kind
> >of escape notation to get into a more recursive syntax such
> >as SDSI or (gasp!) DER, if recursion turns out to be required.
> >However, if you do go for s-exprs, then I would urge you to
> >investigate the possibility of combining X.509's abstract syntax
> >with a more straightforward encoding rule set that produced
> >s-exprs, as I suggest above. Once you allow recursion, the
> >argument for using any other abstract syntax than the
> >existing standard is extremely thin. Moreover, this would
> >seem to be one way to (at least partly) harmonize the
> >SPKI/PKIX efforts. It would mean that certificate creation
> >software could create an SPKI or PKIX cert simply by switching
> >encoders at run time. Certainly, there are more important
> >differences than encoding, but it would be a start.
> This "start" would be a move in a bad direction, IMHO. From that start,
> one might be tempted to actually do what you're calling for -- and that
> might lead to a desire to have SPKI and PKIX certificates have the
> same content.
What's wrong with that? Note that from my POV, there's
no need for a X.509 certificate to actually contain a
real X.500 DN, and so there is no 'global name' that
needs to be there. Without that, the X.509 syntax is
basically a jug (albeit oddly shaped and with the handle on
the bottom :-) into which you can pour whatever you like.
Really, the attributes are the important thing. It would
be nice to have an easy encoding, but less people will
be affected by that than by the choice of attributes
and by the basic stance of the PK infrastructure.