[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enterprise-only or more...
Steve,
OK
-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Thursday, July 05, 2007 9:49 AM
To: Santosh Chokhani
Cc: ietf-trust-anchor@xxxxxxxx
Subject: RE: Enterprise-only or more...
At 2:17 PM -0700 7/3/07, Santosh Chokhani wrote:
>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.
>
I think every TA is nominally limited in scope. For example, there
seems to be agreement that we intend to be able to manage more than
one TA. If we have two or more TAs, and if there is no scope
associated with each of them, we may get into ambiguous or
non-deterministic situations. Even if a TA is authorized to do
everything, I'd like to see that stated explicitly. So I'm not fond
of the "If a TA is limited in scope" part of this definition.
Your list of example scopes is a good start, but "any combination of
the above" to be "tends to counter the notion of these as just
examples.
How about:
A Trust Anchor is a Public key and associated information that a relying
party uses for signature verification. The associated information
often is used to define the scope of a trust anchor, by imposing
constraints on the signatures it may be used to verify. For example,
if a trust anchor is used to verify signatures on X.509 certificates,
these constraints may include a combination of name spaces,
certificate policies, or application/usage types.
Steve