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

Re: encoding: SPKI vs. SDSI

Frank,

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

At 11:59 PM 2/27/97 +0000, Frank O'Dwyer wrote:
>
>> 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'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?



>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 
source.]

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

 - Carl
References: