RE: Enterprise-only or more...

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Steve,

How about the following for a Trust Anchor Definition.

A Trust Anchor is a Public key and associated information that a relying
party uses for signature verification.  If the trust anchor is limited
in scope, the associated information includes the scope.  Examples of
scope are name spaces, certificate policies, application/usage types,
and any combination of the above.

-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx] 
Sent: Tuesday, July 03, 2007 2:50 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor@xxxxxxxx
Subject: RE: Enterprise-only or more...

At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote:
>Steve,
>
>I am resending the text I posted to the list over the weekend.  I
wonder
>if any one read it or found it useful.
>
>
>"The definition of the Trust Anchor is problematic.  The phrase
"highest
>source of trust within a local context" is not clear.  More
importantly,
>the meaning I assign to it contradicts the discussion on this list.

I agree, hence my revised definition in a message earlier today.

>I would say that a Trust Anchor is a Public key and (optionally or
>always) an associated name that a relying party trusts for an unlimited
>scope or a defined scope.  Examples of scope are name spaces,
>certificate policies, application/usage types, and any combination of
>the above.

I don't even like using the word "trust" here.  Lety me know if you 
think my suggested definition is a step in the right direction.

>I also think there is a simpler way to specify the protocol
requirements
>at the top level.
>
>We need to define a protocol that can manage these potentially multiple
>trust anchors that a relying party depends on.  By manage, we mean the
>ability to add, remove or update the trust anchors in the relying party
>system.

agreed.

>The security requirements for the protocol are that the relying party
>must be able to authenticate the source of trust anchor management
>information, must be able to ascertain the authority of the
>authenticated source to update the trust anchor information, and must
be
>able to ascertain that the information has not been changed from what
>the authenticated source intended.

all reasonable requirements.  There may be more that folks will want, 
but this is certainly a solid starting set.

>We would also like the protocol so that once the relying party system
is
>initialized with trust anchor information, the protocol can update the
>trust anchor management information in-band (i.e., without assuming any
>security beyond that afforded by the protocol itself) securely when one
>or more (including all) trust anchors have been compromised and hence
>need to be replaced."

agreed.

Steve