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

RE: Enterprise-only or more...



-----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:
>How about the following for a Trust Anchor Definition.
>A Trust Anchor is a Public key and associated information that a
>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 

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.