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

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

Peter.

----

(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!)