At 4:30 PM -0400 9/10/07, [EMAIL PROTECTED] 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
will want to install TAs that are
constrained in what they are used to verify, which is consistent with
the need to interpret TA data to enforce such constraints.
However, this is perhaps orthogonal to a technically sound TAM solution
(which should allow the Enterprise to designate multiple TAAs
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Stephen Kent
> Sent: Monday, September 10, 2007 12:13 PM
> To: [EMAIL PROTECTED]
> Cc: ietf-trust-anchor@vpnc.org
> Subject: RE: Multiple TAAs
>
.
> >
> &
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
...
Ok, here's that example:
For example, imagine a security device that implements IPsec but also
incorporates application layer proxies as well. The device vendor is
the only authorized source for the IPsec software. One or more other
vendors are authorized sources for the application la
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 hav
David,
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
express the
ld be very useful to constrain the applications that
the delegated-to trust anchor could impact.
Russ
Carl Wallace wrote:
> > At 12:11 PM 8/17/2007, [EMAIL PROTECTED]
wrote:
> > >My preference is that managing different
privileges for
> multiple TAAs
> > >administe
David:
I think we have reached agreement on the vast bulk of the things in
my message and your reply.
One exception:
One more item. Russ wrote:
> I see no reason for there to me more than one all-powerful TA as
> long as the all-powerful TA can be used to make updates to the
> all-powerfu
--
From: Carl Wallace [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 18, 2007 2:36 PM
To: [EMAIL PROTECTED]; Black, David
Cc: ietf-trust-anchor@vpnc.org
Subject: RE: Multiple TAAs
> > 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 c
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
> &g
ggested, that the IT department appoint itself as the one and only
TAA and then repeat all of Microsoft's changes, may be the way
enterprises choose to handle this (either that or outsourcing it like
all other IT). but then you don't need multiple TAAs at all. You may
want to allow
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 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
15 matches
Mail list logo
