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

RE: Multiple TAAs




At 4:30 PM -0400 9/10/07, Black_David@xxxxxxx wrote:
Steve,

 >In the specific area of application proxy software verification,
 >I'm pushing the complexity of determining whether a TA can
 >verify a software package into the PKIX certificate infrastructure
 >that can already handle it - I'd like to keep that area of
 >functionality out of the TA management protocol beyond the
 >ability of a TA to include a certificate.

 If you're saying that the per-vendor granularity is best managed by a
 cert extension of the sort I suggested, I guess I agree. But, that is
 an example of using a cert-specific capability to achieve the needed
 granularity of authorization management.  Is your point that this is
 > now a TA feature, but not TAA feature?

Yes, specifically:

 > I might
 > be about to concede part of Steve's point by arguing that for the
 > proxy trust store, the TA has to include a certificate signed by
 > the device vendor and the prefix OID of the packages that TA can
 > verify has to be in the certificate.

and the code that handles proxy software download knows to check that
OID against the code package.


David,

OK. I am clearer on what you're thinking is here.

I am concerned that, in order to adopt the simple TA store model, we have to make other software be more knowledgeable about the authorization semantics associated with signatures. I guess we have a law of conservation of complexity at work here :-), i.e., we're moving complexity from one area (TA management) into another (signed package processing).

I agree that one can do this, but the result is a less full-featured TA management capability than what I had envisioned was required.

I'll see if I can come up with examples where the management of TAs per se requires interpretation of TA data, and is not satisfied by the TA store model.

Stev e