[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enterprise-only or more...
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.
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Tuesday, July 03, 2007 2:50 PM
To: Santosh Chokhani
Subject: RE: Enterprise-only or more...
At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote:
>I am resending the text I posted to the list over the weekend. I
>if any one read it or found it useful.
>"The definition of the Trust Anchor is problematic. The phrase
>source of trust within a local context" is not clear. More
>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
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
>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
>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
>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
>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."