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

Re: streaming (was Re: propagation control)


> Notice that the canonical encoding we have proposed for S-expressions and 
> the original -00.txt binary encoding were both streamable.  As you walked a 
> structure, you could feed bytes to a hash function.  When you are done with 
> the walk, you call SHAFinal().

This is the main property I want, the ability to sign a data structure 
without having to construct an intermediate buffer with the encoded
representation.

I want to be able to write a function SPKI (object, algorithm, meta_data)
which returns the SPKI encoding of the object. I want that function to
be linear in time complexity and require only stack space for recursion.


Being able to write that sort of function would allow the type of generic
assertional substrate that generalizes annotations, certificates and PICS.

Consider the following type of certificate:-

The following sites are known to sign their documents as follows:
    http://www.whitehouse.gov/ DSS:127398987234
    http://pub3.pub.whitehouse.gov/ DSS:362136
    [signed] security officer

I would expect people to have similar files for email. The difference in this
approach is that the cert does not specify a binding from a key to a user,
it specifies an _expectation_ of how it will be used. 

Consider my inbox which has several messages from Peter Williams, some are
signed, others are not. I am not really interested in the cert saying that
key foobar is bound to Peter Williams. What I would really like is an
inference engine that causes the mail client to scream blue murder if
it gets an email claiming to be from Peter WITHOUT a sig.

I get the feeling that various people have had ideas of this type but
I haven;t heard it said in that form.


I see the SPKI project as involving three basic documents:-

1) Specification of a canonical encoding scheme for a data structure FOO.

2) Specification of a "certificate structure", that is a data structure
	that represents an authenticated assertion within a particular
	intersubjective belief system.

3) An intersubjective belief system for public keys relating to individuals
	and organizations e.g. SDSI.


Given the above documents we can create additional assertion systems
using different semantic principles, different interpretations of names
etc etc.

The key thing to avoid is trying to insist that the semantics of the
belief system be formally defined in a single calculus. That type of 
conformity is just not practical.

So far I think we have a working understanding of _a_ solution for (1),
Ron's recent suggestion sounds good enough to me to use as a working
solution. I have a feeling that (2) and (3) may be conflated. I see
the basic certificate data structure as :-

certificate STRUCTURE 
    a	assertion
    s	List [signature_blob]

assertion STRUCTURE
    b	belief_system_identifier
    t	List [tag_value]

signature_blob STRUCTURE
    id	signature_key_identifier
    v	signature_value
	{Being the value of SIG [alg, ENCODE[assertion], id] }

The above may seem to introduce the possibility of infinite recursion 
since the bindings of belief_system_identifier and signature_key_identifier
may be subjective and hence require the use of a cert to interpret them.

This is not in fact the case, belief_system_identifier is a pure name.
It's meaning is derrived from its use, it is not necessary to perform
a retrieval operation on belief_system_identifier to use it.

[This is a key departure from PICS where the ratings schema is 
specified in an unfortunate manner, the idea that the URL of the rating 
scheme should produce a description of it was intended as a convention, 
this was forgotten later on and the result is well what it is.]

Similarly the term signature_key_identifier is intended to introduce 
a URI denoting the signature key. the certificate format need not consider
how this is achieved. The important point is only that a correspondence
is established.

Each belief system is free to specify whatever means it choses to 
define bindings from URI space to keyspace. It is advisable for these to
follow established conventions where possible but not essential. The
point is that the interpretation of the signature_key_identifier is integral
to the belief system and not to the certificate structure.


Finally there is the specification of a simple belief system:

First we define an identifier for the belief system eg:
http://hallam.net/phillsworld/v1.1

Although each belief system is formally independent the owner of a piece of
URI space might specify a convention for version control when setting out the
beleif system in the first place. The URI need not be a URL, the meaning of
the belief system is not affected by the result of performing GET(URL).
There is no need for the URI to support the GET method at all, or for that
matter be in DNS space (consider ISBN:21362172349867 as a URI).

Next we have an interpretation of signature identifier URIs:

If the URI is of the form X509:197349217498213 interpret the number as the
certificate UID of an X509 certificate, consider the key to be the
subject key of the certificate

If the URI is of the form RSA:2387287:2138746123: interet the first number 
as the value of the public exponent, the second as the modulus, the third as 
the value of e.

If the URI is of the form SPKI:hallam@foobar:1 then consider the key to be
the SPKI certificate created within this belief system with subject 
hallam@foobar and key serial number 1 

[and so on] - This part of the spec would be likely to be adopted by 
most other belief systems but decoupling it from the certificate standard
obviates the need to version the certificate format.


Finally we need to define the attribute tags and corresponding data types 
for the assertions.


One thought that came to mind while writing this, instead of specifying one
belief system identifier it might be usefull to allow a list to be specified
instead. This would be equivalent to providing a "courtesy list" defining
an inheritance structure for belief systems. This would allow phillsworld
to extend SPKI by adding a couple of extra attributes without having to 
restate SPKI in phillsworld.


I'm sorry to be so long winded but people were complaining about complexity.
I think that the core of the system can be very very simple. The complexity
lies in defining new belief systems.

	Phill

PS This is not PICS, this is what it might have been had the timetable for
development not been set by Senators Exon and Valdez.
Follow-Ups: References: