Too bad as in general the overall policy enforcement requires other "trust anchors", "roots of trust", "assertion authorities", to be pre-configured, like attribute- and authorization authorities.
Furthermore, it also would disallow the use of other authentication and key exchange mechanism to bootstrap from, like secure-password/shared-secret protocols with online CAs, in which case there would be no need for any trust-anchor's public key and no digital signature. Just to support x509/pkix style identity certs based on only public keys and only dsigs makes it just as "useful" as x509/pkix... maybe this trust-anchor protocol shouldn't deserve its own wg and should instead be used to "revive" pkix as it clearly deals with a deficiency not addressed in pkix's gazillion rfcs ;-) -FS. Paul Hoffman wrote: > At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >> The notion of trust anchors has been, for the last 15 years or so, a >> purely public key notion. So yes, I would argue that if we want to >> work on what it going to be called a trust anchor management protocol, >> it needs to be based on public keys and signature validation. If >> folks want to do something else, make up a new name, this one is taken >> :-). > > I agree with Steve. Everyone involved so far has been talking about > public keys, which if nothing else shows that this is the common theme. > > --Paul Hoffman, Director > --VPN Consortium > -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory
