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

RE: Enterprise-only or more...




On Sat, 30 Jun 2007, Turner, Sean P. wrote:
Check out:
http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-08.txt Page

To quote:

	Trust anchor
      (I) /PKI/ An established point of trust (usually based on the
      authority of some person, office, or organization) from which a
      certificate user begins the validation of a certification path.
      (See: apex trust anchor, path validation, trust anchor CA, trust
      anchor certificate, trust anchor key.)

      Usage: IDOCs that use this term SHOULD state a definition for it
      because it is used in various ways in existing IDOCs and other PKI
      literature. The literature almost always uses this term in a sense
      that is equivalent to this definition, but usage often differs
      with regard to what constitutes the point of trust.

I'll grant that it's only a SHOULD to have IDOCs state a definition for TA,
but given the discussion on the list, combined with the SHOULD, it seems to
me that we SHOULD ;)

The quoted definition seems reasonable to me, however.

cheers!

-----Original Message-----
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
[mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Stefan Santesson
Sent: Friday, June 29, 2007 7:35 AM
To: Thomas Hardjono; Stephen Kent; Paul Hoffman
Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
Subject: RE: Enterprise-only or more...


I would like to be slightly more pragmatic.

1) Definition of TA.
This is something we need before a BOF. A TA is obviously a public key that
is the highest source of trust. The question is for whom and within what
context. I think the only reasonable answer is that a TA is always a TA
within a local context. What is TA for me may not be a TA for you.

We also have different level of trust infrastructures serving each others.
We may have a trust management infrastructure based on a trusted directory
that uses one TA. This infrastructure may then used to distribute TAs for
local applications through a directory based infrastructure. In other cases
the security infrastructure is flat (i.e. for some devices) where we resort
to manual procedures.

Attempt at definition:
Trust Anchor: A public key that acts as a highest source of trust within a
local context. A TA may also include parameters that constrain the context
of trust it is intended to serve.


2) What protocols to standardize
In the Enterprise environment a local system using TAs is often subordinate
to one ore more management systems with its own security model. This might
be a directory centric solution distributing information over a secured
network. Example: I bring my device/computer on the physical corporate
network where it is initialized through admin passwords or tokens and in
that process an number of TAs are imported that makes it possible to
communicate remotely in the future with the enterprise network and update
TAs for local applications.

In the flat device scenario which I assume can be mobile devices, network
routers, domain name servers etc, which are not tied to a common database or
directory, TA management needs to cover the complete sets of security needs
on its own.

Common for all scenarios seems to be the potential need for a common format
for the TA object itself and the parameters it is associated with.

Therefore one candidate for a standard could be a TA object format
including:
- A public key (in the form of key + key parameters, or a self signed
certificate
- Optional additional parameters constraining trust in the public key, and
- An optional signature

There are situations when a self signed certificate is not desired. This is
the case when I pick a public key from a trusted CA that I do not control
and which self signed root I don't have.


What more can we reasonably do? Currently I can't see it.
I doubt we can define a generic exchange protocol.
- For the device scenario I would suspect that any exchange protocol if
necessary need to be defined in a more local application context. E.g. DNS
SEC has its own solution and mobile devices have another while wireless
access points a third.

- For the Enterprise model I would think that the means of exchange will be
defined by local directory schemas or databases having their own security
model that would be hard to standardize.


Is there anything else?



Stefan Santesson
Senior Program Manager
Windows Security, Standards


-----Original Message-----
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx [mailto:owner-ietf-trust-
anchor@xxxxxxxxxxxxx] On Behalf Of Thomas Hardjono
Sent: den 27 juni 2007 00:02
To: Stephen Kent; Paul Hoffman
Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
Subject: RE: Enterprise-only or more...




-----Original Message-----
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
[mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Stephen
Kent
Sent: Tuesday, June 26, 2007 12:57 PM
To: Paul Hoffman
Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
Subject: Re: Enterprise-only or more...


At 12:40 PM -0700 6/26/07, Paul Hoffman wrote:
At 1:30 PM +0100 6/22/07, Stephen Farrell wrote:
...

If there is one TA admin, and that person is someone other than me,
then your model does not work. That is, the bank needs to get the
single TA admin to bless the bank's TA.

If there is more than one TA admin (say, a real TA admin plus the
user controlling the application), then the bank only needs to
convince one of the (probably the user) to install the bank's TA.

I think a reasonable requirement is that the protocol allow the
client to specify more than one TA admins. If that requirement is
met, a system where the user really does control the system can
simply name the user as a TA admin.

There are multiple reasonable models.

For example, a device may be "owned" by a vendor who delegates to a
user or local admin the authority to install TAs with certain scope,
but not all TAs. This might be a model for desk top boxes or cell
phones.

In an enterprise context, a local admin may want a similar capability
for himself, delegating some control to individual users, but
retaining ultimate control over TA management for a desktop or laptop.

Steve


Seems to me that we could have several issues/aspects pertaining to
TAs:

(1) Definition of a TA (ie. structure, syntax, semantics)
(2) Protocol(s) to "manage" TAs (and definition/scope of what we mean
by the term "manage")
(3) Authorization model (ie. authorization to manage TAs)
(4) Delegation model (i.e. authority-over-TA now delegates portions of
authority or entire authority)
(5) Others...

The scope of the BOF/WG can easily become very wide, which is why I
was suggesting that the Enterprise use-case may be more manageable :)

/thomas/











==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."