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

[peter@verisign.com: a number of points on SPKI rationale]

Very nice, Peter!  I was amused myself at how close this discussion
was getting to the ASN.1 tarpit.  I think that with some appropriate
ASN.1 tutorials posted to the SPKI group, you could get some recruits
for ASN.1!  

I agree with Carl Ellison's recent (private) comments that there seems
to be a fundamental divide between using S-expressions as a data
structure, and using various kinds "structures a C or PASCAL
programmer would normally write".

Perhaps the SDSI involvement in SPKI is indeed taking SPKI too far
away from its charter, and we should give up on trying to unify them.
SDSI is quite firmly in the S-expression camp, and I don't see how to
make a compromise on the syntax issue work out.  At the higher level,
they fit together quite nicely.   

Perhaps someone else can think of a way.  At the moment, my
inclination is to continue working on the S-expression style.  If SPKI
decides to work with S-expressions cleanly, then perhaps we can
continue to work together.  But perhaps S-expressions are just too far
away from the SPKI charter and the sentiments of its members.

To comments on some of your specific remarks:

(1) Yes, for S-expressions it is necessary to have a small decoder.
    And of course some error-checking will take place to check consistency
    and completeness, as is necessary with any data structure that is
    more complicated than a pure byte string.

(2) You ask if an incorrectly formatted S-expression can produce a 
    valid signature verification result.  It is possible to sign any
    S-expression, even one which appears to be a "certificate" but
    is missing an "issuer" field, for example.  I don't think that
    this is different with other formats.  The verifier has to check
    that what is signed actually makes sense--he can't trust the
    signer to do that for him.

(3) S-expressions are an abstract data type with many possible representations
    as an ASCII string.  (I.e. many possible transfer syntaxes).  One
    may choose one way for email robustness, and another for compactness,
    and a third way for signatures.  If you want to enclose an
    S-expression in a header field of SMTP, you get to choose an
    appropriate encoding that is compatible.  (What are the constraints
    that need to be satisfied here?)

(4) For using S-expressions for message origin authentication on MTA's,
    the nodes may indeed have to do some S-expression parsing.  But
    this is linear in the size of the message, whereas the crypto work
    tends to be quadratic in the size of the key (or worse, as for DSA).
    Why do you want to validate the origin signature at each node, instead
    of doing end-to-end authentication?

(5) The big-endian encoding does seem to require an extra pass when
    processing to get the data aligned on the boundaries right.  This
    again, is not a terribly big point.

	Ron Rivest
Return-Path: <owner-spki@c2.net>
To: spki@c2.net
From: Peter Williams <peter@verisign.com>
Subject: a number of points on SPKI rationale

"  An SPKI certificate should be described in as simple a method as
   possible, relating directly to the kind of structures a C or PASCAL
   programmer would normally write.

   No library code should be required for the packing or parsing of SPKI
   certificates.  In particular, ASN.1 is not to be used.

   A certificate should be signed exactly as it is transmitted.  There
   should be no reformatting called for in the process of checking a
   certificate's signature (although one might canonicalize white space
   during certificate input, for example, if the format is text)."

(a) very few pascal programmers write recursive list parsers (though ASN.1/BER
programmers do it all the time :-) )

I note now that the phrase is very clever - an SPKI cert should be 
"described" in ... This requirement seems limited to requiring a particular
form for the SPKI specifications, not for constraining the presentation,
transfer or signing form.

(b) from the list discussion, it looks like a small decoding library
will be needed.  It unclear whether the decoder and parser will be
required to do type checking to ensure tag consistency, length
consistency etc. The degree to which the verifier of a certificate
should enforce outer BNF type consistency during validation of the
signature operator, enforce consistency of any
locally-registered/globally-allocated tags and their data types,
and/or make the best attempt to parse the syntax or abandon upon
syntax error, is unclear.

Can a presentation syntax which is known to be badly generated produce
a successful signature validate result?

(c) the transfer syntax rules being proposed would seem to violate the
last paragraph quoted. The rules are more than canonicalization; they
constitute a possible increase in size of the data structure due to
signing due to method of coding the explicit length component of the
TLV. (**)

Assuming the Rivest encoding rules are used for hashing, in which form
is the expression transmitted? { canonical/encoded-form, S-expression
notation} in a header field of SMTP, say?

If a message origin authentication signature is validated by each MTA
en route (alot for usenet) using such certs, presentation in S-expr
form means the internet must do alot more work than perhaps it might
need to do forever recoding for hashing prior to validating the
signature and then perhaps authorizing the msg relay to the next MTA.
   "For efficiency, if possible, an SPKI certificate should be encoded in
>   an LR(0) grammar.  That is, neither packing nor parsing of the
>   structure should require a scan of the data.  Data should be read
>   into the kind of structure a programmer would want to use without
>   touching the incoming bytes more than once."

If a tag implies a data item is an integer, and said datum is a
bignum, we have already heard testimony that one encoding specified by
the chair (big-endian) requires in reality two-pass
decoding/fitting-to-aligned-memory in contradiction to the



(soap for offline flames: this TLV encoding stuff is currently so close
(98%) to
ASN.1/BER [with privately-defined numeric tags], its hard to believe SPKI
started out
based upon a rejection of ASN.1 design principles! Converting ASN.1/BER
decoding code to do SPKI/SDSI encoding/decoding and recursive list
data representation should be trivial. Great news!)