Frank, In your scenario, it seems you do not need trust anchor albeit it is not clear how communication to online CA is secured and how trust is extended beyond on-line CA.
You say, "In those cases, there already are ways to establish a secure authenticated communication context with a trust-anchor provisioning service". What is this trust-anchor provisioning service; what is trust anchor contents in your context; Is the trust anchor local, enterprise wide or covers multiple enterprises; and how do you (I assume meaning client or relying parties) establish secure authenticated communication with the trust-anchor provisioning service. -----Original Message----- From: Frank Siebenlist [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 11:12 AM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter In our deployments, we see more and more that PKI is not the primary authentication mechanism and that online-CAs are used to obtain pk-credentials, which means that this pki-trust is derived from other already pre-configured primary authentication mechanisms, like shared secrets, username/password, kerberos, OTP, etc. In those cases, there already are ways to establish a secure authenticated communication context with a trust-anchor provisioning service, and the requirement to use only public key and dsig is not very "helpful" in those scenarios. -FS. Santosh Chokhani wrote: > Frank, > > I agree with Steve. I will be willing to expand the notion a bit. But, > in my thinking this deals with cryptographic protocols. These protocols > require a public or secret key to establish the trust for authentication > and integrity checks. Thus, it must be a key. As it so happens, we > have been dealing with PKI related matters and hence the starting key > for authentication and integrity is a public key. > > In short, any idea for trust anchor that does not deal with a crypto key > is a loser from crypto viewpoint. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Frank > Siebenlist > Sent: Tuesday, August 21, 2007 1:40 AM > To: Paul Hoffman > Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > 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
