RE: Draft Charter

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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:franks@xxxxxxxxxxx] 
Sent: Tuesday, August 21, 2007 11:12 AM
To: Santosh Chokhani
Cc: ietf-trust-anchor@xxxxxxxx
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: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Frank
> Siebenlist
> Sent: Tuesday, August 21, 2007 1:40 AM
> To: Paul Hoffman
> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@xxxxxxxx
> 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               franks@xxxxxxxxxxx
The Globus Alliance - Argonne National Laboratory