[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.
Cheers,
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
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!)
Follow-Ups: