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
Henry,
> > This gets back to the issue I cited earlier, and reiterated several
> > times. Each TAA has to have an ability to associate some scope with
> > it. This scope may have to be imposed on TAs installed "under" each
> > TAA. That way one can use static analysis of TAAs to determine
>
Steve,
> I agree that if multiple TAAs are completely independent of one
> another, the simplest approach is to treat the stores as independent.
>
> Complexity arises when different TAAs are not completely independent.
> If there are relationships among TAAs, then we have to be able to
> exp
That's correct, and I'm in favor of calling out the concept
of a TSA explicitly in order to avoid some of the confusion
we've gotten into on the list.
Thanks,
--David
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkint
> >As for the TAA definition, how about:
> >
> >A Trust Anchor Administrator (TAA) is the entity represented by the
trust
> >anchor. The TAA controls the private key of the trust anchor.
>
> A public key with associated crypto parameters and associated
> restrictions do not "represent" anyone.
Frank,
> Your "translation" sounds good ;-)
>
> I just don't understand your concern about tls with pre-shared secret
-
> kerberos' security would be enhanced when it would deploy that for
it's
> password-based authN+keyexchange - it seems to me like a better authN
> protocol to use for any pass
> In all cases, we would like to standardize the trust root provisioning
> protocol without having to mandate any boots-trapping public key. Just
> having the message exchange protocol with standardized formats for the
> trust-anchor info including meta-data for the anchor's issuing
> constraints
Carl,
> Why limit the arrangement such that the contracted service can manage
everything?
Why not? In particular, I see profound contractual difficulties if the
enterprise
can't trust the contracted service to manage all the trust anchors - if
it's not
trusted for that, what else is it not tru
Russ,
> At 12:11 PM 8/17/2007, [EMAIL PROTECTED] wrote:
> >My preference is that managing different privileges for multiple
> >TAAs administering the same trust anchor store ought to be out of
> >scope, unless someone has a compelling use case with which to argue
> >otherwise.
>
> I think we nee
I want to expand on something I said at the microphone in Chicago -
I think the easiest (and likely to be the most common) solution to
multiple TAAs that don't have the same management privileges is
separate trust anchor stores and that an operational model of all
TAAs for a trust anchor store ha
10 matches
Mail list logo
