dangers of TCPA/palladium

[Brian A. LaMacchia]

Adam Shostack <adam at homeport.org> wrote:
> On Mon, Aug 12, 2002 at 12:38:42AM -0700, Brian A. LaMacchia wrote:
>> There are two parts to answering the first question:
>>
>> 1) People (many people, the more the merrier) need to understand the
>> code and what it does, and thus be in a position to be able to make
>> an informed decision about whether or not they trust it.
>> 2) People reviewing the code, finding security flaws, and then
>> reporting them so that we can fix them
>>
>> These are two very different things.  I don't think that anyone
>> should count on the goodwill of the general populace to make their
>> code proveably secure. I think that paying people who are experts at
>> securing code to find exploits in it must be part of the development
>> process.
>
> How are these different?  If I'm understanding the code to decide if I
> trust it (item 1), it seems to me that I must do at least 2A and 2B:
> 2C is optional :)
>
> Or are you saying that (2) is done by internal folks, and thus is a
> smaller set than (1)?

Yeah, I wasn't very clear here, was I?  What I was trying to say was that
there's a difference between understanding how a system behaves technically
(and deciding whether that behavior is correct from a technical perspective)
and understanding how a system behaves from a policy perspective (e.g.
social process & impact).  Those are two completely different questions.  2)
is all about verifying that Palladium hardware and software components
technically operates as it is spec'd to.  1) is about the larger issue of
how Palladium systems interact with service providers (CAs, TTPs), what
processes one goes through to secure PII, etc.  The two groups of people
looking at 1) and 2) have non-zero intersection but are not equal.  And,
just to be clear, 2) is *not* done only by internal folks, but I expect that
the size of the set of people competent to do 2) is significantly smaller
than the size of the set of people who need to think about 1). :-)

                    --bal


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com