[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.

Frank O'Dwyer.

Follow-Ups: References: