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

Comments on SPKI draft of 25 March 1997

On object names:

The proposal envisions two types of object names, the "long form" and
the "short form", as in
	c = certificate
	na = not-after
and so on.  

I would argue AGAINST having two forms of any object names (except for
case variations) as follows:

-- consider the two reasons for having two forms:
	-- readability (favors the longer forms)
	-- compression (favors the shorter forms)

-- but consider that the real benefit of the compression gained is small:
	if we have an object of the form
		( name parameters )
        and we shorten the name by 5 bytes, we KNOW that the
        parameters will be at least 100 bytes, we haven't really saved that
        much.  Much of the "real data" will be incompressible hashes and
        public keys, so the benefit is not large. 

        For example, the difference between
		( public-key .... )
                ( k .... )
        (the proposed alternative), is likely to be less than 10%, given that
        the key data itself is going to be more than 100 bytes, and we only
        saved 9 characters.

        As another example, the difference between
		( not-after 1997-05-07_12:30:47 )
		( na 1997-05-07_12:30:47 )
        (the proposed alternative) is less than 25%.  

        Considering the overall mix of data we will be seeing, I think that
        the proposed compression techniques are likely to yield an overall
        savings of less than 15%.  Unless the savings were shown to be over 
        50%, I think that it isn't worth complexifying the _Simple_ public-key
        infrastructure proposal.

Thus, I propose having just the longer forms, so we retain the
readability, we little penalty in terms of compression, and some
savings in terms of implementation complexity.  Also, readability is
very important when presenting the design to others; achieving the
ultimate in compression is not so important if it makes "selling" the
design more difficult.  Simpler is better.

This also simplifies the BNF, since you can get rid of the type metavariables
such as
and just use the single type name

Ron Rivest