[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: encoding: SPKI vs. SDSI
> At the December meeting, when I suggested that it might be easier to merge
> with SDSI if we adopt S-expression encoding rather than our current binary
> proposal, I heard objections -- both to ASCII and to S-expressions.
If it is s-exprs you want, you could simply use X.509's abstract
syntax "as is", but with an s-expr encoding rule set in place of
BER/DER. If it is 'optional' elements that are the concern, then
a solution is to profile those elements in or out. One ASN.1
compiler (pepsy) already produces and consumes an ASCII encoding
that resembles s-exprs, "out of the box". You could feed in X.509
and PKCS to pepsy and crank out the s-expr equivalents automatically.
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.
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.
Cheers,
Frank O'Dwyer.
Follow-Ups:
References: