Re: brands v/s types Bill Frantz (frantz@netcom.com)
Thu, 19 Jun 1997 10:16:21 -0700

At 10:38 AM -0700 6/18/97, Jonathan S. Shapiro wrote:
>First, note that this only impacts tests of authenticity/officialness.
>It does not impact factory-based object generation. For factories, the
>chain of trust is based on the factory being a factory and on the factory
>installing the proper program segment, not on the brand.
>
>Factories trust each other by virtue of branding. In this instance, the
>chain of trust is:
>
> correct brand guaranteed program built by factory creator
> program build by factory creator runs proper code seg
>
>Note that proper code seg is known not to bash brand, but if it does it
>simply means that the factory no longer authenticates as a factory.

Proper code segment is a red herring. If you don't want the code segment to be a hole, all you have to do is give the factory a R/O, NoCall key to the segment. You can keep a R/W key to the segment for yourself and then change the code weeks or years later. In KeyKOS we used this mechanism for code upgrade.

There is also the issue of something which has been authenticated, but then is changed later to be something different. In a "type safe" system this change could be a disaster. We didn't protect against this kind of change in KeyKOS, but we did protect against changing the available outward communication paths. (Just changing the code segment does not increase the number of outward communication channels.)

>
>> Some of the proposals seem to enlarge the 3rd party authenticity
>> security kernel. Enlargement makes verification harder.
>
>Which proposals enlarge the security kernel? Being able to 'write' the
>brand increases false negatives, not false positives. All the other
>operations are equivalents to the current system.

I need to read between the lines a bit here. I assume that the domain creators remains the only class which holds the domain tool, and the only way to verify the brand is using the domain tool.

In KeyKOS, the brand was set to a key to the domain creator. (I can't remember which one.) This approach leaves the possibility that any holder of the any domain creator could brand any domain-key with that brand, a bad situation.

If the domain creation tools are tightly held by domain creators, and no domains are returned unless they are branded, and the "only allow change if DK(0)" approach is taken, then proposal (1) is the same as needing the domain tool in KeyKOS.

If on the other hand, there is a SB(getDomain==>c;D) call which returns an unbranded domain, then domain creators have to carefully control access to their branding keys in order to keep the identification portion of their contract.

As you say, the secrecy of the brand is vital. While your proposals keep the brand secret when stored in the domain, I don't see enough of the rest of the system to know how other copies of the key which is stored there are controlled. 

Bill Frantz       | The Internet was designed  | Periwinkle -- Consulting
(408)356-8506     | to protect the free world  | 16345 Englewood Ave.
frantz@netcom.com | from hostile governments.  | Los Gatos, CA 95032, USA