Draft Charter

[Turner, Sean P.]

Attached is a draft of the charter that was distributed prior to the
meeting. Primarily we need to discuss the scenarios
(enterprise/non-enterprise) and scoping (browsers/devices/etc).

spt

PS thanks for all the participation at the BOF!

[Paul Hoffman]

At 6:55 PM -0400 8/9/07, Turner, Sean P. wrote:
>Strawman charter for trust anchor management (tam) BoF
>
>Version: 01, July 9th 2007
>
>Chair(s)
>
>TBD
>
>Security Area Director(s):
>
>- Tim Polk <tim.polk-R3+/***@public.gmane.org>
>- Sam Hartman <hartmans-ietf-***@public.gmane.org>
>
>Security Area Advisor:
>
>TBD
>
>Mailing Lists:
>
>General Discussion: ietf-trust-anchor-***@public.gmane.org
>To Subscribe: http://www.vpnc.org/ietf-trust-anchor/
>Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/
>
>Description of Working Group:
>
>The need for a standard protocol for trust anchor management has been
>recognized for some time. Many groups within the IETF, including PKIX,
>Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no
>generic mechanism for the their management.

Editorial nit: a comma is needed after "SIDR".

>
>
>A trust anchor is a public key and associated data used by a relying party to
>begin the process of validating a signature on a signed object.
>Associated data
>is used to define the scope of the use of the trust anchor for validating
>signatures; for example, associated data might limit the types of identifiers
>in certificates that a trust anchor is allowed to validate.
>
>Despite the wide-spread use of trust anchors, there is no standard means for
>managing these security-critical data. This Working Group will develop a
>specification to fill this gap.
>
>The initial problem statement for this work is to be based on:
>
>- draft-wallace-ta-mgmt-problem-statement
>
>The scope of the work is to include:
>
><<list to be developed in Chicago>>

Chicago is now in the past; elide that.

>- Supporting a single trust anchor administrator, such as in a typical
> enterprise, who may be administering multiple trust anchors in her domain,
> where those trust anchors can be either local or "foreign"
>- Supporting multiple trust anchor administrators, such as is typical for home
> users
>- Supporting devices with limited or no user interface that may or
>may not have
> connected to the Internet

Some of the questions at the mic made it clear that people had issues
with user interface. It might be better to separate that out into two
bullet items:

- Supporting systems with limited or no user interface

- Supporting devices that may or many not be connected to the
Internet at the time of management

>
>The following are out of scope of this work:
>
><<list to be developed in Chicago>>
>- TBD

I think this is non-controversial for out-of-scope:

- Management of non-anchor signature validation objects such as
intermediate certificates in a validation path.

This might be more controversial, but should be considered as out-of-scope:

- Mandating whether the recipient of trust anchors from a trust
anchor manager will use those anchors

>
>The deliverables will be:
>
>- An informational problem statement/requirements specification
> for a trust anchor management protocol
>- A standards track trust anchor management protocol
> specification
>
>Goals and Milestones:
>
>+6 months WG last call on problem statement/requirements
>+9 months Adoption of WG draft protocol spec.
>+15 months WG last call for protocol spec.
>
>

--Paul Hoffman, Director
--VPN Consortium

[Turner, Sean P.]

Draft 02 of the charter captures these, which I will distribute after some
more discussion on the TA definition.

>-----Original Message-----
>From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>[mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of
>Paul Hoffman
>Sent: Friday, August 10, 2007 10:51 AM
>To: ietf-trust-anchor-***@public.gmane.org
>Subject: Re: Draft Charter
>
>
>At 6:55 PM -0400 8/9/07, Turner, Sean P. wrote:
>>Strawman charter for trust anchor management (tam) BoF
>>
>>Version: 01, July 9th 2007
>>
>>Chair(s)
>>
>>TBD
>>
>>Security Area Director(s):
>>
>>- Tim Polk <tim.polk-R3+/***@public.gmane.org>
>>- Sam Hartman <hartmans-ietf-***@public.gmane.org>
>>
>>Security Area Advisor:
>>
>>TBD
>>
>>Mailing Lists:
>>
>>General Discussion: ietf-trust-anchor-***@public.gmane.org To Subscribe:
>>http://www.vpnc.org/ietf-trust-anchor/
>>Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/
>>
>>Description of Working Group:
>>
>>The need for a standard protocol for trust anchor management has been
>>recognized for some time. Many groups within the IETF,
>including PKIX,
>>Kerberos, TLS and SIDR have a dependency on trust anchors,
>yet provide
>>no generic mechanism for the their management.
>
>Editorial nit: a comma is needed after "SIDR".
>
>>
>>
>>A trust anchor is a public key and associated data used by a relying
>>party to begin the process of validating a signature on a
>signed object.
>>Associated data
>>is used to define the scope of the use of the trust anchor for
>>validating signatures; for example, associated data might limit the
>>types of identifiers in certificates that a trust anchor is
>allowed to validate.
>>
>>Despite the wide-spread use of trust anchors, there is no standard
>>means for managing these security-critical data. This Working Group
>>will develop a specification to fill this gap.
>>
>>The initial problem statement for this work is to be based on:
>>
>>- draft-wallace-ta-mgmt-problem-statement
>>
>>The scope of the work is to include:
>>
>><<list to be developed in Chicago>>
>
>Chicago is now in the past; elide that.
>
>>- Supporting a single trust anchor administrator, such as in a typical
>> enterprise, who may be administering multiple trust
>anchors in her domain,
>> where those trust anchors can be either local or "foreign"
>>- Supporting multiple trust anchor administrators, such as is
>typical for home
>> users
>>- Supporting devices with limited or no user interface that
>may or may
>>not have
>> connected to the Internet
>
>Some of the questions at the mic made it clear that people had
>issues with user interface. It might be better to separate
>that out into two bullet items:
>
>- Supporting systems with limited or no user interface
>
>- Supporting devices that may or many not be connected to the
>Internet at the time of management
>
>>
>>The following are out of scope of this work:
>>
>><<list to be developed in Chicago>>
>>- TBD
>
>I think this is non-controversial for out-of-scope:
>
>- Management of non-anchor signature validation objects such
>as intermediate certificates in a validation path.
>
>This might be more controversial, but should be considered as
>out-of-scope:
>
>- Mandating whether the recipient of trust anchors from a
>trust anchor manager will use those anchors
>
>>
>>The deliverables will be:
>>
>>- An informational problem statement/requirements specification
>> for a trust anchor management protocol
>>- A standards track trust anchor management protocol
>> specification
>>
>>Goals and Milestones:
>>
>>+6 months WG last call on problem
>statement/requirements
>>+9 months Adoption of WG draft protocol spec.
>>+15 months WG last call for protocol spec.
>>
>>
>
>--Paul Hoffman, Director
>--VPN Consortium
>

[Stephen Kent]

Sean,

Some more comments on the charter text:

A trust anchor is a public key and associated data used by a relying party to
begin the process of validating a signature on a signed object.

At least in the X.509 context, we often end to use the term "verify"
for signatures, and validate for certs, although we are not
absolutely consistent in this usage. RFC 2828 discusses this in the
section entitled "validate vs. verify" and I suggest we adopt the
suggested usage guidelines from there.

"begin" may still be problematic, e.g., because one might argue that
the beginning of the signature validation process is path discovery.
Unfirtunately I don't have a good alternative suggestion right now.

Associated data is used to define the scope of the use of the trust
anchor for validating signatures. For example, associated data might
limit the types of identifiers in certificates that a public key is
used to validate, or the types of objects the signatures of which can
be verified using a public key.

The suggested rewording adheres to the validate vs. verify model in
2828, avoids recursive use of the term TA in its own definition, and
extends the example to encompass non-cert signed data.

The scope section seems confusing to me:

- Supporting a single trust anchor administrator, such as in a typical
enterprise, who may be administering multiple trust anchors in her domain,
where those trust anchors can be either local or "foreign"

We have not defined "local" or "foreign" so it's hard to understand
the importance of the distinction being drawn here.

- Supporting multiple trust anchor administrators, such as is typical for home
users

Why do we believe it is common for a home user to need multiple TA
administrators?

- Supporting devices with limited or no user interface that may or
may not have connectivity to the Internet

a simple typo fix, but if a deliverable is a TA management protocol,
then why do we worry about devices that have no Internet connectivity?

Steve

[Santosh Chokhani]

Steve,



Would the following do?



A relying party uses the trust anchor and associated information to
verify signature on the first certificate in a certification path. If
there are no certificates (i.e., the trusted anchor has directly signed
an object), the relying party uses the trust anchor and associated
information to verify signature on the signed object.



________________________________

From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
[mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Stephen Kent
Sent: Friday, August 10, 2007 12:10 PM
To: turners-***@public.gmane.org
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: Re: Draft Charter



Sean,



Some more comments on the charter text:



A trust anchor is a public key and associated data used by a relying
party to

begin the process of validating a signature on a signed object.



At least in the X.509 context, we often end to use the term "verify" for
signatures, and validate for certs, although we are not absolutely
consistent in this usage. RFC 2828 discusses this in the section
entitled "validate vs. verify" and I suggest we adopt the suggested
usage guidelines from there.



"begin" may still be problematic, e.g., because one might argue that the
beginning of the signature validation process is path discovery.
Unfirtunately I don't have a good alternative suggestion right now.



Associated data is used to define the scope of the use of the trust
anchor for validating signatures. For example, associated data might
limit the types of identifiers in certificates that a public key is used
to validate, or the types of objects the signatures of which can be
verified using a public key.



The suggested rewording adheres to the validate vs. verify model in
2828, avoids recursive use of the term TA in its own definition, and
extends the example to encompass non-cert signed data.



The scope section seems confusing to me:



- Supporting a single trust anchor administrator, such as in a typical
enterprise, who may be administering multiple trust anchors in her
domain,

where those trust anchors can be either local or "foreign"



We have not defined "local" or "foreign" so it's hard to understand the
importance of the distinction being drawn here.


- Supporting multiple trust anchor administrators, such as is typical
for home

users



Why do we believe it is common for a home user to need multiple TA
administrators?



- Supporting devices with limited or no user interface that may or may
not have connectivity to the Internet



a simple typo fix, but if a deliverable is a TA management protocol,
then why do we worry about devices that have no Internet connectivity?



Steve

[Stephen Farrell]

That definition is x.509 specific ("certificate"). While that
may be what emerges as the consensus wrt scope for this proposed
work, we shouldn't decide that this way IMO.

S.

Santosh Chokhani wrote:
> Steve,
>
>
>
> Would the following do?
>
>
>
> A relying party uses the trust anchor and associated information to
> verify signature on the first certificate in a certification path. If
> there are no certificates (i.e., the trusted anchor has directly signed
> an object), the relying party uses the trust anchor and associated
> information to verify signature on the signed object.
>
>
>
> ------------------------------------------------------------------------
>
> *From:* owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] *On Behalf Of *Stephen Kent
> *Sent:* Friday, August 10, 2007 12:10 PM
> *To:* turners-***@public.gmane.org
> *Cc:* ietf-trust-anchor-***@public.gmane.org
> *Subject:* Re: Draft Charter
>
>
>
> Sean,
>
>
>
> Some more comments on the charter text:
>
>
>
> A trust anchor is a public key and associated data used by a relying
> party to
>
> begin the process of validating a signature on a signed object.
>
>
>
> At least in the X.509 context, we often end to use the term "verify" for
> signatures, and validate for certs, although we are not absolutely
> consistent in this usage. RFC 2828 discusses this in the section
> entitled "validate vs. verify" and I suggest we adopt the suggested
> usage guidelines from there.
>
>
>
> "begin" may still be problematic, e.g., because one might argue that the
> beginning of the signature validation process is path discovery.
> Unfirtunately I don't have a good alternative suggestion right now.
>
>
>
> Associated data is used to define the scope of the use of the trust
> anchor for validating signatures. For example, associated data might
> limit the types of identifiers in certificates that a_ public key is
> used to validate, or the types of objects the signatures of which can be
> verified using a public key_.
>
>
>
> The suggested rewording adheres to the validate vs. verify model in
> 2828, avoids recursive use of the term TA in its own definition, and
> extends the example to encompass non-cert signed data.
>
>
>
> The scope section seems confusing to me:
>
>
>
> - Supporting a single trust anchor administrator, such as in a typical
> enterprise, who may be administering multiple trust anchors in her domain,
>
> where those trust anchors can be either local or "foreign"
>
>
>
> We have not defined "local" or "foreign" so it's hard to understand the
> importance of the distinction being drawn here.
>
>
> - Supporting multiple trust anchor administrators, such as is typical
> for home
>
> users
>
>
>
> Why do we believe it is common for a home user to need multiple TA
> administrators?
>
>
>
> - Supporting devices with limited or no user interface that may or may
> not have_ connectivity_ to the Internet
>
>
>
> a simple typo fix, but if a deliverable is a TA management* protocol*,
> then why do we worry about devices that have no Internet connectivity?
>
>
>
> Steve
>

[Santosh Chokhani]

What is X.509 specific?

The term certificate or certification path or both. Will PGP and others
not have a chain of keys/certificates?

Are not these concepts generic and is this not time to separate concepts
from X.509 format?

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell-aVqd/T0vMsmzQB+***@public.gmane.org]
Sent: Friday, August 10, 2007 3:37 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: Re: Draft Charter


That definition is x.509 specific ("certificate"). While that
may be what emerges as the consensus wrt scope for this proposed
work, we shouldn't decide that this way IMO.

S.

Santosh Chokhani wrote:
> Steve,
>
>
>
> Would the following do?
>
>
>
> A relying party uses the trust anchor and associated information to
> verify signature on the first certificate in a certification path. If

> there are no certificates (i.e., the trusted anchor has directly
signed
> an object), the relying party uses the trust anchor and associated
> information to verify signature on the signed object.
>
>
>
>
------------------------------------------------------------------------
>
> *From:* owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] *On Behalf Of *Stephen
Kent
> *Sent:* Friday, August 10, 2007 12:10 PM
> *To:* turners-***@public.gmane.org
> *Cc:* ietf-trust-anchor-***@public.gmane.org
> *Subject:* Re: Draft Charter
>
>
>
> Sean,
>
>
>
> Some more comments on the charter text:
>
>
>
> A trust anchor is a public key and associated data used by a relying
> party to
>
> begin the process of validating a signature on a signed object.
>
>
>
> At least in the X.509 context, we often end to use the term "verify"
for
> signatures, and validate for certs, although we are not absolutely
> consistent in this usage. RFC 2828 discusses this in the section
> entitled "validate vs. verify" and I suggest we adopt the suggested
> usage guidelines from there.
>
>
>
> "begin" may still be problematic, e.g., because one might argue that
the
> beginning of the signature validation process is path discovery.
> Unfirtunately I don't have a good alternative suggestion right now.
>
>
>
> Associated data is used to define the scope of the use of the trust
> anchor for validating signatures. For example, associated data might
> limit the types of identifiers in certificates that a_ public key is
> used to validate, or the types of objects the signatures of which can
be
> verified using a public key_.
>
>
>
> The suggested rewording adheres to the validate vs. verify model in
> 2828, avoids recursive use of the term TA in its own definition, and
> extends the example to encompass non-cert signed data.
>
>
>
> The scope section seems confusing to me:
>
>
>
> - Supporting a single trust anchor administrator, such as in a typical
> enterprise, who may be administering multiple trust anchors in her
domain,
>
> where those trust anchors can be either local or "foreign"
>
>
>
> We have not defined "local" or "foreign" so it's hard to understand
the
> importance of the distinction being drawn here.
>
>
> - Supporting multiple trust anchor administrators, such as is typical
> for home
>
> users
>
>
>
> Why do we believe it is common for a home user to need multiple TA
> administrators?
>
>
>
> - Supporting devices with limited or no user interface that may or may

> not have_ connectivity_ to the Internet
>
>
>
> a simple typo fix, but if a deliverable is a TA management* protocol*,

> then why do we worry about devices that have no Internet connectivity?
>
>
>
> Steve
>

[Stephen Farrell]

Santosh Chokhani wrote:
> What is X.509 specific?
>
> The term certificate or certification path or both.

Yes. For me anyway, particularly the latter term.

> Will PGP and others
> not have a chain of keys/certificates?

Who knows? (Can't recall off the top of my head what the
PGP things are called - not keyrings was it?)

> Are not these concepts generic and is this not time to separate concepts
> from X.509 format?

That would be a worthwhile activity. But not one that it'd be wise
to build in as a precondition on this proposed activity. So I'd rather
see a definition use more neutral terms.

S.

>
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell-aVqd/T0vMsmzQB+***@public.gmane.org]
> Sent: Friday, August 10, 2007 3:37 PM
> To: Santosh Chokhani
> Cc: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
> That definition is x.509 specific ("certificate"). While that
> may be what emerges as the consensus wrt scope for this proposed
> work, we shouldn't decide that this way IMO.
>
> S.
>
> Santosh Chokhani wrote:
>> Steve,
>>
>>
>>
>> Would the following do?
>>
>>
>>
>> A relying party uses the trust anchor and associated information to
>> verify signature on the first certificate in a certification path. If
>
>> there are no certificates (i.e., the trusted anchor has directly
> signed
>> an object), the relying party uses the trust anchor and associated
>> information to verify signature on the signed object.
>>
>>
>>
>>
> ------------------------------------------------------------------------
>> *From:* owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] *On Behalf Of *Stephen
> Kent
>> *Sent:* Friday, August 10, 2007 12:10 PM
>> *To:* turners-***@public.gmane.org
>> *Cc:* ietf-trust-anchor-***@public.gmane.org
>> *Subject:* Re: Draft Charter
>>
>>
>>
>> Sean,
>>
>>
>>
>> Some more comments on the charter text:
>>
>>
>>
>> A trust anchor is a public key and associated data used by a relying
>> party to
>>
>> begin the process of validating a signature on a signed object.
>>
>>
>>
>> At least in the X.509 context, we often end to use the term "verify"
> for
>> signatures, and validate for certs, although we are not absolutely
>> consistent in this usage. RFC 2828 discusses this in the section
>> entitled "validate vs. verify" and I suggest we adopt the suggested
>> usage guidelines from there.
>>
>>
>>
>> "begin" may still be problematic, e.g., because one might argue that
> the
>> beginning of the signature validation process is path discovery.
>> Unfirtunately I don't have a good alternative suggestion right now.
>>
>>
>>
>> Associated data is used to define the scope of the use of the trust
>> anchor for validating signatures. For example, associated data might
>> limit the types of identifiers in certificates that a_ public key is
>> used to validate, or the types of objects the signatures of which can
> be
>> verified using a public key_.
>>
>>
>>
>> The suggested rewording adheres to the validate vs. verify model in
>> 2828, avoids recursive use of the term TA in its own definition, and
>> extends the example to encompass non-cert signed data.
>>
>>
>>
>> The scope section seems confusing to me:
>>
>>
>>
>> - Supporting a single trust anchor administrator, such as in a typical
>> enterprise, who may be administering multiple trust anchors in her
> domain,
>> where those trust anchors can be either local or "foreign"
>>
>>
>>
>> We have not defined "local" or "foreign" so it's hard to understand
> the
>> importance of the distinction being drawn here.
>>
>>
>> - Supporting multiple trust anchor administrators, such as is typical
>> for home
>>
>> users
>>
>>
>>
>> Why do we believe it is common for a home user to need multiple TA
>> administrators?
>>
>>
>>
>> - Supporting devices with limited or no user interface that may or may
>
>> not have_ connectivity_ to the Internet
>>
>>
>>
>> a simple typo fix, but if a deliverable is a TA management* protocol*,
>
>> then why do we worry about devices that have no Internet connectivity?
>>
>>
>>
>> Steve
>>
>
>

[Santosh Chokhani]

Steve,

It may be better if we agreed on how generic this definition needs to
be. What communities are having trouble understanding these terms and
what their recommendations are.

I have been monitoring this list and I feel that most people on the list
know what trust anchor is. Thus, rather than perfecting the definition,
we may be better served discussing the scope of TAMP, benefits of having
TAMP, and by generating implementers interest based on these benefits.

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell-aVqd/T0vMsmzQB+***@public.gmane.org]
Sent: Friday, August 10, 2007 3:47 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: Re: Draft Charter



Santosh Chokhani wrote:
> What is X.509 specific?
>
> The term certificate or certification path or both.

Yes. For me anyway, particularly the latter term.

> Will PGP and others
> not have a chain of keys/certificates?

Who knows? (Can't recall off the top of my head what the
PGP things are called - not keyrings was it?)

> Are not these concepts generic and is this not time to separate
concepts
> from X.509 format?

That would be a worthwhile activity. But not one that it'd be wise
to build in as a precondition on this proposed activity. So I'd rather
see a definition use more neutral terms.

S.

>
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell-aVqd/T0vMsmzQB+***@public.gmane.org]
> Sent: Friday, August 10, 2007 3:37 PM
> To: Santosh Chokhani
> Cc: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
> That definition is x.509 specific ("certificate"). While that
> may be what emerges as the consensus wrt scope for this proposed
> work, we shouldn't decide that this way IMO.
>
> S.
>
> Santosh Chokhani wrote:
>> Steve,
>>
>>
>>
>> Would the following do?
>>
>>
>>
>> A relying party uses the trust anchor and associated information to
>> verify signature on the first certificate in a certification path.
If
>
>> there are no certificates (i.e., the trusted anchor has directly
> signed
>> an object), the relying party uses the trust anchor and associated
>> information to verify signature on the signed object.
>>
>>
>>
>>
>
------------------------------------------------------------------------
>> *From:* owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] *On Behalf Of *Stephen
> Kent
>> *Sent:* Friday, August 10, 2007 12:10 PM
>> *To:* turners-***@public.gmane.org
>> *Cc:* ietf-trust-anchor-***@public.gmane.org
>> *Subject:* Re: Draft Charter
>>
>>
>>
>> Sean,
>>
>>
>>
>> Some more comments on the charter text:
>>
>>
>>
>> A trust anchor is a public key and associated data used by a relying
>> party to
>>
>> begin the process of validating a signature on a signed object.
>>
>>
>>
>> At least in the X.509 context, we often end to use the term "verify"
> for
>> signatures, and validate for certs, although we are not absolutely
>> consistent in this usage. RFC 2828 discusses this in the section
>> entitled "validate vs. verify" and I suggest we adopt the suggested
>> usage guidelines from there.
>>
>>
>>
>> "begin" may still be problematic, e.g., because one might argue that
> the
>> beginning of the signature validation process is path discovery.
>> Unfirtunately I don't have a good alternative suggestion right now.
>>
>>
>>
>> Associated data is used to define the scope of the use of the trust
>> anchor for validating signatures. For example, associated data might
>> limit the types of identifiers in certificates that a_ public key is
>> used to validate, or the types of objects the signatures of which can
> be
>> verified using a public key_.
>>
>>
>>
>> The suggested rewording adheres to the validate vs. verify model in
>> 2828, avoids recursive use of the term TA in its own definition, and
>> extends the example to encompass non-cert signed data.
>>
>>
>>
>> The scope section seems confusing to me:
>>
>>
>>
>> - Supporting a single trust anchor administrator, such as in a
typical
>> enterprise, who may be administering multiple trust anchors in her
> domain,
>> where those trust anchors can be either local or "foreign"
>>
>>
>>
>> We have not defined "local" or "foreign" so it's hard to understand
> the
>> importance of the distinction being drawn here.
>>
>>
>> - Supporting multiple trust anchor administrators, such as is typical

>> for home
>>
>> users
>>
>>
>>
>> Why do we believe it is common for a home user to need multiple TA
>> administrators?
>>
>>
>>
>> - Supporting devices with limited or no user interface that may or
may
>
>> not have_ connectivity_ to the Internet
>>
>>
>>
>> a simple typo fix, but if a deliverable is a TA management*
protocol*,
>
>> then why do we worry about devices that have no Internet
connectivity?
>>
>>
>>
>> Steve
>>
>
>

[Jon Callas]

On Aug 10, 2007, at 12:46 PM, Stephen Farrell wrote:

>
>
>
> Santosh Chokhani wrote:
>> What is X.509 specific?
>> The term certificate or certification path or both.
>
> Yes. For me anyway, particularly the latter term.
>
> > Will PGP and others
>> not have a chain of keys/certificates?
>
> Who knows? (Can't recall off the top of my head what the
> PGP things are called - not keyrings was it?)
>

They're called "certificates." The process where by one certificate
certifies another one is something we call "certification."

I know that sounds flippant, but it isn't. More below. I wasn't going
to send this note at all until we got into discussions of what format
certificates TAM ought to address.


>> Are not these concepts generic and is this not time to separate
>> concepts
>> from X.509 format?
>
> That would be a worthwhile activity. But not one that it'd be wise
> to build in as a precondition on this proposed activity. So I'd rather
> see a definition use more neutral terms.
>

An historical note first. The term "key" for "certificate" in the way
that it is colloquially used in OpenPGP was coined by Whit Diffie.
People like it. It's short, friendly, and has a nice provenance.

However, it isn't accurate. A certificate contains a key, but a
certificate is not a key.

Worse, an OpenPGP certificate typically contains at least two public
keys, along with a number of certifications. (It is possible to have
a one-key OpenPGP certificate, but that can only be used for signing.
If you want to encrypt something, you need a signing key and an
encryption key in your certificate. Right now, we're moving to a use
model that has at least three keys -- where the top level signing key
is merely a certification key, and there's an encryption and signing
subkey. This is particularly popular in Europe.)

What this means is that if you say "OpenPGP Key" and want to talk
about its components, you're using the word "key" far too many times.
I have tried to apply rigor to the terminology, but people like using
the word "key" for "certificate" and refused to play along. So I
merely get precise when I need to.

X.509 has a much more atomic model of certificates, but you can
create the same structures of an OpenPGP certificate with a handful
of X.509 certificates. Likewise, you can take a "certificate set" or
"certificate family" of X.509 certificates and create an OpenPGP
certificate out of them.

(Note that I'm simplifying here. I don't have time to write, nor you
to read the constraints and further explanations I want to write.)

There is a *syntactic* isomorphism between OpenPGP and X.509. The
differences are in the semantics, but you can express those semantics
with either syntax. I sometimes think of this in a graph-theoretic
way, and in that mode of thought, the primary X.509 object is a node
+edge pair, from which you then make up graphs, and the OpenPGP
object is a small graph, which contains nodes and edges. Another
metaphor is that X.509 starts with quarks and builds up atoms, while
OpenPGP starts with atoms that contain quarks. I like this one
because in physics, atoms are not atomic, and they are not atomic for
historical reasons.

Now where the OpenPGP and X.509 (particularly PKIX) models diverge is
an attitude about issuers and roots. In OpenPGP, every user is a
potential CA. Every certificate is a potential root. This makes for
some semantic differences, as well as attitude differences.

Every so often, a PKIX/X.509 discussion comes up about using the same
public key in more than one certificate. One thing that always comes
out of that discussion is noting that if you did it, you'd need a way
to revoke a public key as well as a certificate, and no such thing
exists. Well, OpenPGP effectively does this by having both a
signature revocation and a "key" revocation mechanism. Note that in
*this* case, the OpenPGP colloquialism of "key" actually means a key!

(If Alice and Bob each certify my "key," that corresponds to my
having three X.509 certificates, each with the same public key. My
"key" is three certs, one issued by Alice, one issued by Bob, and one
that is self-signed. If I revoke my self-signed certificate, that
implies revoking the other two. Yes, I know all the things you're
thinking now.)

So let me get to keyrings, and then back to TAM. There's no such
thing as a keyring. More precisely, it is not well-defined. That file
you have for PGP or GnuPG is a sequential file of OpenPGP
certificates, nothing more. However, a "keyring" could also be an SQL
database containing same. So if you permit me to contradict myself, a
"keyring" is nothing more than a certificate database with a warm,
fuzzy, Diffie-coined word for it, and is often implemented as a flat
file.

OpenPGP makes a show of explicitly not defining how to express trust.
This is because when the OpenPGP working group was formed, we were
told we couldn't be a PKI, and that meant we couldn't standardize
trust. So while there is a "trust packet" in OpenPGP, it's officially
implementation-dependent. As it turns out by some happy coincidence,
we all base our trust structures on what went before, and we can
(usually) directly import these from one implementation to another.

And this is why TAM would be useful to OpenPGP, and why you'll find
slightly tepid comments from some people. Historically, we've solved
these problems among ourselves, and typically it all works just fine.
In other words, TAM gives X.509 ways to do things that OpenPGP has
done for a long time.

However, I know there are rough edges, and TAM would be a fine way to
iron them out. For my company, PGP Corporation, we work in PKIs that
are imaged into X.509 syntax and OpenPGP syntax. We need to maintain
parallel structures, and TAM is a fine way to do it.

If TAM becomes PKIX-only, then I'm going to have to make a TAM
extension to handle certs in different formats. I can think now of a
way to do it:

I go look at whatever TAM decides, and go directly to where the ASN.1
says "certificate goes here." And then I just put there instead of
the certificate a type-constant (an OID?) and then the certificate.
Then poof, Alice is your auntie, and we're all done.

Is it *that* hard to make this part of TAM, and have type constants
for PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.?

Jon

--
Jon Callas
CTO, CSO
PGP Corporation Tel: [phone]
3460 West Bayshore Fax: [phone]
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d

[Stephen Kent]

At 2:47 PM -0700 8/13/07, Jon Callas wrote:
>...
>An historical note first. The term "key" for "certificate" in the
>way that it is colloquially used in OpenPGP was coined by Whit
>Diffie. People like it. It's short, friendly, and has a nice
>provenance.

I believe the term "certificate" was coined in an MIT bachelor's
thesis by Kornfelder in 1978. (Ron Rivest was the thesis advisor.).
The original D-H paper in 1976 had no concept of a cert; instead it
talked about making public keys available in a phone book like manner.

>However, it isn't accurate. A certificate contains a key, but a
>certificate is not a key.

right.

>Worse, an OpenPGP certificate typically contains at least two public
>keys, along with a number of certifications. (It is possible to have
>a one-key OpenPGP certificate, but that can only be used for
>signing. If you want to encrypt something, you need a signing key
>and an encryption key in your certificate. Right now, we're moving
>to a use model that has at least three keys -- where the top level
>signing key is merely a certification key, and there's an encryption
>and signing subkey. This is particularly popular in Europe.)

this recursive definition of a cert may be a good example of why it
may be hard to develop a protocol that uses a consistent set of
terminology and embraces both OPGP and X.509/PKIX.

>What this means is that if you say "OpenPGP Key" and want to talk
>about its components, you're using the word "key" far too many
>times. I have tried to apply rigor to the terminology, but people
>like using the word "key" for "certificate" and refused to play
>along. So I merely get precise when I need to.

on this list you probably should assume the need to be precise :-).

>...
>
>
>Now where the OpenPGP and X.509 (particularly PKIX) models diverge
>is an attitude about issuers and roots. In OpenPGP, every user is a
>potential CA. Every certificate is a potential root. This makes for
>some semantic differences, as well as attitude differences.
>
>Every so often, a PKIX/X.509 discussion comes up about using the
>same public key in more than one certificate. One thing that always
>comes out of that discussion is noting that if you did it, you'd
>need a way to revoke a public key as well as a certificate, and no
>such thing exists. Well, OpenPGP effectively does this by having
>both a signature revocation and a "key" revocation mechanism. Note
>that in *this* case, the OpenPGP colloquialism of "key" actually
>means a key!

There are a lot of reasons why it is preferable to not reuse a public
key in multiple certs. The semantics of X.509 deal with cert
revocation because a CA's job is to vouch for the binding of the
attributes in a cert and the public key in that cert. Revocaton of
the cert breaks the binding, which is both necessary and sufficient
for the semantic model. There is not need to add an ability to
revoke keys, because a CA does not attest to the security of the key
in any larger sense.

>(If Alice and Bob each certify my "key," that corresponds to my
>having three X.509 certificates, each with the same public key. My
>"key" is three certs, one issued by Alice, one issued by Bob, and
>one that is self-signed. If I revoke my self-signed certificate,
>that implies revoking the other two. Yes, I know all the things
>you're thinking now.)

I'd try to avoid that last phrase as it may strike some as both
presumptuous and, at least in my case, usually wrong :-).

>So let me get to keyrings, and then back to TAM. There's no such
>thing as a keyring. More precisely, it is not well-defined. That
>file you have for PGP or GnuPG is a sequential file of OpenPGP
>certificates, nothing more. However, a "keyring" could also be an
>SQL database containing same. So if you permit me to contradict
>myself, a "keyring" is nothing more than a certificate database with
>a warm, fuzzy, Diffie-coined word for it, and is often implemented
>as a flat file.

a clear definition for a key ring would not require any mention of
the type of database by which the set of certs is maintained, so,
hopefully, there is a better reason that the term is not defined in
any documents, right?

>OpenPGP makes a show of explicitly not defining how to express
>trust. This is because when the OpenPGP working group was formed, we
>were told we couldn't be a PKI, and that meant we couldn't
>standardize trust. So while there is a "trust packet" in OpenPGP,
>it's officially implementation-dependent. As it turns out by some
>happy coincidence, we all base our trust structures on what went
>before, and we can (usually) directly import these from one
>implementation to another.

This is a very odd characterization. Despite the blatant overuse of
the term, especially in marketing literature and poorly written
papers, both the syntax and semantics of X.509 can be described w/o
reference to the word "trust." (Even the term "trust anchor" need not
be defined using the word trust, as the candidate definitions bandied
about on this list have shown.)

>And this is why TAM would be useful to OpenPGP, and why you'll find
>slightly tepid comments from some people. Historically, we've solved
>these problems among ourselves, and typically it all works just
>fine. In other words, TAM gives X.509 ways to do things that OpenPGP
>has done for a long time.

Is this another set of things that OPGP does but which is not
documented in any IETF publication?

>However, I know there are rough edges, and TAM would be a fine way
>to iron them out. For my company, PGP Corporation, we work in PKIs
>that are imaged into X.509 syntax and OpenPGP syntax. We need to
>maintain parallel structures, and TAM is a fine way to do it.
>
>If TAM becomes PKIX-only, then I'm going to have to make a TAM
>extension to handle certs in different formats. I can think now of a
>way to do it:
>
>I go look at whatever TAM decides, and go directly to where the
>ASN.1 says "certificate goes here." And then I just put there
>instead of the certificate a type-constant (an OID?) and then the
>certificate. Then poof, Alice is your auntie, and we're all done.
>
>Is it *that* hard to make this part of TAM, and have type constants
>for PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.?


Syntax is not the hard part here.

For example, when one defines the language needed to characterize the
constraints ompised on TAAs, and the constraints expressible via a TA
data structure, one probably has to be cognizant of the semantics of
the certs being managed, else there will be no way to ensure that the
language has enough richness to meet the requirements of the target
user community (whoever we decide that to be). For example, in the
X.509 context, it seems likely that we need the ability to express
name constraints, maybe policy constraints, certainly RFC 3779
constraints, etc.

Also, what is SAML doing in your list? It is not a PKI mechanism,
not a public key format, ...

Steve

[Stephen Farrell]

Hi Jon,

Thanks for the interesting post - that's actually clarified
a few pgp things for me that I've always glossed over.

Jon Callas wrote:
[...good stuff, then...]
> Is it *that* hard to make this part of TAM, and have type constants for
> PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.?

Tend to agree. One more TLV isn't very much to ask at all, assuming
this becomes a new WG. If this work were to be done inside PKIX then
that extra TLV would probably open too many cans of worms, perhaps
sufficient to make that good idea become a bad idea;-)

Cheers,
S.

[Jon Callas]

On Aug 10, 2007, at 12:39 PM, Santosh Chokhani wrote:

>
> What is X.509 specific?
>
> The term certificate or certification path or both. Will PGP and
> others
> not have a chain of keys/certificates?

I presume you mean OpenPGP. PGP is software, and it is software that
implements X.509 as well as OpenPGP.


>
> Are not these concepts generic and is this not time to separate
> concepts
> from X.509 format?

Yes.

Jon

--
Jon Callas
CTO, CSO
PGP Corporation Tel: [phone]
3460 West Bayshore Fax: [phone]
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d

[Stephen Kent]

At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote:
>Steve,
>
>Would the following do?

slightly re-worded, to reflect the notion that a TA consists of both
a public key and associated info, and that one verifies a signature
with a TA, vs. signing an object with a TA:


"A relying party uses a trust anchor to verify the signature on the
first certificate in a certification path, or is used to directly
verify the signature on a signed object when no certification path is
involved."

[Santosh Chokhani]

Steve,



Sounds good.



________________________________

From: Stephen Kent [mailto:kent-A08e6c8yq/***@public.gmane.org]
Sent: Friday, August 10, 2007 3:58 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: RE: Draft Charter



At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote:

Steve,



Would the following do?



slightly re-worded, to reflect the notion that a TA consists of both a
public key and associated info, and that one verifies a signature with a
TA, vs. signing an object with a TA:





"A relying party uses a trust anchor to verify the signature on the
first certificate in a certification path, or is used to directly verify
the signature on a signed object when no certification path is
involved."

[Turner, Sean P.]

(sorry I'm jumping back to this)

I think we should add the following as the first sentence: "A trust anchor
is an established point of trust, which is usually based on the authority of
some person, office or organization." [Shirey] I think we should do this
because we jumped right in to how it's used not what it is. I used Rob's
definition because I think it hit the mark.

(I think) The rest of the argument about the TA definition is then based on
the context in which you want to use the TA. As the basis of trust for a
PKI, the Relying Party (RP) uses the TA to verify signatures on public key
certificates. As the basis of trust for object X (which happens to be
directly signed by a TA), the RP uses the TA to verify the signatures on
object X.

If we added the first sentence and modified what was below to: "In a PKI
context, a relying party uses a trust anchor to verify the signature on the
first certificate in a certification path or a CRL signed directly by the
TA. In other contexts, a relying party uses a trust anchor directly to
verify the signature on a signed object when no certification path is
involved."

?

spt

[Shirey] Shirey, R., "Internet Security Glossary, Version 2",
work-in-progress, November 2006.

________________________________

From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
[mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Santosh Chokhani
Sent: Friday, August 10, 2007 8:47 PM
To: Stephen Kent
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: RE: Draft Charter

Steve,

Sounds good.

________________________________

From: Stephen Kent [mailto:kent-A08e6c8yq/***@public.gmane.org]
Sent: Friday, August 10, 2007 3:58 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: RE: Draft Charter



At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote:

Steve,

Would the following do?

slightly re-worded, to reflect the notion that a TA consists of both
a public key and associated info, and that one verifies a signature with a
TA, vs. signing an object with a TA:

"A relying party uses a trust anchor to verify the signature on the
first certificate in a certification path, or is used to directly verify the
signature on a signed object when no certification path is involved."

[Stephen Kent]

At 2:41 PM -0400 8/16/07, Turner, Sean P. wrote:
>(sorry I'm jumping back to this)
>
>I think we should add the following as the first sentence: "A trust anchor
>is an established point of trust, which is usually based on the authority of
>some person, office or organization." [Shirey] I think we should do this
>because we jumped right in to how it's used not what it is. I used Rob's
>definition because I think it hit the mark.
>

Although Rob worked for me for many years, and I generally like his
security glossary, I can't say that I find this definition great.

The definition uses the word "trust," which is generally mushy. It
tries to qualify that by alluding to authority, which I think is
really is central to the issue, especially for TAM. This may be an
example of how an attempt to be very general produces a watered-down
definition.

Also, absent the further examples you give, but describe as
context-specific, the quoted text is not technically useful, i.e.,
without the examples the definition doesn't tell me if a TA is a
public key or a fruit :-).

Steve

[Turner, Sean P.]

>-----Original Message-----
>At 2:41 PM -0400 8/16/07, Turner, Sean P. wrote:
>>(sorry I'm jumping back to this)
>>
>>I think we should add the following as the first sentence: "A trust
>>anchor is an established point of trust, which is usually
>based on the
>>authority of some person, office or organization." [Shirey] I
>think we
>>should do this because we jumped right in to how it's used
>not what it
>>is. I used Rob's definition because I think it hit the mark.
>>
>
>Although Rob worked for me for many years, and I generally
>like his security glossary, I can't say that I find this
>definition great.
>
>The definition uses the word "trust," which is generally
>mushy. It tries to qualify that by alluding to authority,
>which I think is really is central to the issue, especially
>for TAM. This may be an example of how an attempt to be very
>general produces a watered-down definition.
>
>Also, absent the further examples you give, but describe as
>context-specific, the quoted text is not technically useful,
>i.e., without the examples the definition doesn't tell me if a
>TA is a public key or a fruit :-).
>
>Steve

I thought there might have been some connection with you and Rob ;)

The glossary's definition had more in the 1st sentence which basically said
what the suggested second sentence said - so I get your point about mushy
fruit. I agree that the authority is a central concept to TAM and that's
what I was alluding to with my context comment. I think it ought to be in
the definition. How about:

A trust anchor is a public key and associated data that represents an
authoritative source of some type of information. Associated data is used
to define the scope of the use of the trust anchor including the authorized
type of information.

spt

[Stephen Kent]

At 12:09 PM -0400 8/18/07, Turner, Sean P. wrote:
>...
>
>The glossary's definition had more in the 1st sentence which basically said
>what the suggested second sentence said - so I get your point about mushy
>fruit. I agree that the authority is a central concept to TAM and that's
>what I was alluding to with my context comment. I think it ought to be in
>the definition. How about:
>
>A trust anchor is a public key and associated data that represents an
>authoritative source of some type of information. Associated data is used
>to define the scope of the use of the trust anchor including the authorized
>type of information.
>
>spt

Sean,

I still find this too mushy :-). I'd like to see some mention of
digital signatures in the definition. That seems to be an essential
feature of TAs, irrespective of the use of certs (of any type) vs.
raw keys.

Steve

[Diego R. Lopez]

On 20 Aug 2007, at 19:49, Stephen Kent wrote:
> At 12:09 PM -0400 8/18/07, Turner, Sean P. wrote:
>> ...
>>
>> The glossary's definition had more in the 1st sentence which
>> basically said
>> what the suggested second sentence said - so I get your point
>> about mushy
>> fruit. I agree that the authority is a central concept to TAM and
>> that's
>> what I was alluding to with my context comment. I think it ought
>> to be in
>> the definition. How about:
>>
>> A trust anchor is a public key and associated data that represents an
>> authoritative source of some type of information. Associated data
>> is used
>> to define the scope of the use of the trust anchor including the
>> authorized
>> type of information.
> I still find this too mushy :-). I'd like to see some mention of
> digital signatures in the definition. That seems to be an essential
> feature of TAs, irrespective of the use of certs (of any type) vs.
> raw keys.

Ditto. In despite of the format used (certificates or whatever), a TA
deals with the verification
of digital signatures.



--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: diego.lopez-***@public.gmane.org
jid: drlopez-bva+***@public.gmane.org
Tel: [phone]
Mobile: [phone]
-----------------------------------------

[Paul Hoffman]

At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote:
>Would the following do?
>
>A relying party uses the trust anchor and associated information to
>verify signature on the first certificate in a certification path.
> If there are no certificates (i.e., the trusted anchor has directly
>signed an object), the relying party uses the trust anchor and
>associated information to verify signature on the signed object.

Not for me. We do not need to be using "certificates" here. A
specific use case that does not involve certificates is a trust
anchor that directly signs objects that the device uses such as trust
anchor management messages.

Even if we are in a PKIX-centric world, not everything is a certificate.

--Paul Hoffman, Director
--VPN Consortium

[Paul Hoffman]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Draft Charter</title></head><body>
<div>At 12:10 PM -0400 8/10/07, Stephen Kent wrote:</div>
<blockquote type="cite" cite><font color="#000000">At least in the
X.509 context, we often end to use the term &quot;verify&quot; for
signatures, and validate for certs, although we are not absolutely
consistent in this usage.&nbsp; RFC 2828 discusses this in the section
entitled &quot;validate vs. verify&quot; and I suggest we adopt the
suggested usage guidelines from there.</font></blockquote>
<div><br></div>
<div>Even without the RFC 2828 definitions, I think it is good to talk
about &quot;verifying&quot; signatures instead of &quot;validating&quot;
signatures.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">&quot;begin&quot;
may still be problematic, e.g., because one might argue that the
beginning of the signature validation process is path discovery.
Unfirtunately I don't have a good alternative suggestion right
now.</font></blockquote>
<div><br></div>
<div>Let's leave it as &quot;begin&quot; until we have a better word.
I think everyone understands it.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">Associated data is
used to define the scope of the use of the trust anchor for validating
signatures. For example, associated data might limit the types of
identifiers in certificates that a<u> public key is used to validate,
or the types of objects the signatures of which can be verified using
a public key</u>.</font></blockquote>
<div><br></div>
<div>This sounds good too.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">The scope section
seems confusing to me:</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">- Supporting a
single trust anchor administrator, such as in a typical<br>
&nbsp; enterprise, who may be administering multiple trust anchors in
her domain,</font></blockquote>
<blockquote type="cite" cite><font color="#000000">&nbsp; where those
trust anchors can be either local or
&quot;foreign&quot;</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">We have not defined
&quot;local&quot; or &quot;foreign&quot; so it's hard to understand
the importance of the distinction being drawn
here.</font></blockquote>
<div><br></div>
<div>The bullet works just as well without the last clause. That is,
there is no assumption in the words before it that the trust anchors
are all run by the TAA.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">- Supporting
multiple trust anchor administrators, such as is typical for
home</font></blockquote>
<blockquote type="cite" cite><font color="#000000">&nbsp;
users</font></blockquote>
<blockquote type="cite" cite><font face="Courier" size="+2"
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">Why do we believe
it is common for a home user to need multiple TA
administrators?</font></blockquote>
<div><br></div>
<div>I would be happy if we swapped &quot;individual&quot; for
&quot;home&quot;. If needed, we can add text such as &quot;For
example, they may want their employers and their banks to act as trust
anchor administrators.&quot;</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">- Supporting
devices with limited or no user interface that may or may not have<u>
connectivity</u> to the Internet</font></blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>a simple typo fix, but if a deliverable
is a TA management<b> protocol</b>, then why do we worry about devices
that have no Internet connectivity?</blockquote>
<div><br></div>
<div>Protocols do not require Internet connectivity. End-to-end email
is a good example of that.</div>

<div><br>
--Paul Hoffman, Director<br>
--VPN Consortium</div>
</body>
</html>

[Stephen Kent]

At 1:21 PM -0700 8/10/07, Paul Hoffman wrote:
>... the TAA.
>
>>- Supporting multiple trust anchor administrators, such as is
>>typical for home
>> users
>>
>>Why do we believe it is common for a home user to need multiple TA
>>administrators?
>
>I would be happy if we swapped "individual" for "home". If needed,
>we can add text such as "For example, they may want their employers
>and their banks to act as trust anchor administrators."

Ah, I see your point. If I can appropriately constrain the impact of
what a TAA can do, I can safely let others be TAAs for my machine.
That seems right for my home machine, but for a company-owned machine
the roles probably are reversed, i.e., the employer is in charge and
will allow the employee limited control over TAs.

>
>>- Supporting devices with limited or no user interface that may or
>>may not have connectivity to the Internet
>>
>>a simple typo fix, but if a deliverable is a TA management
>>protocol, then why do we worry about devices that have no Internet
>>connectivity?
>
>Protocols do not require Internet connectivity. End-to-end email is
>a good example of that.

Good point. We may want to define protocols that can use staged
delivery, even if there is no network involved. If that's the
intent, the bullet could be a bit clearer, e.g., if we want to define
protocols that work even if we deliver messages via a USB token from
a source to a destination. However, I note that a protocol of that
sort is likely to be more complex than one that assumes use of lower
layer network protocols, even staged delivery ones.

Steve

[Paul Hoffman]

At 4:41 PM -0400 8/10/07, Stephen Kent wrote:
>At 1:21 PM -0700 8/10/07, Paul Hoffman wrote:
>>... the TAA.
>>
>>>- Supporting multiple trust anchor administrators, such as is
>>>typical for home
>>> users
>>>
>>>Why do we believe it is common for a home user to need multiple TA
>>>administrators?
>>
>>I would be happy if we swapped "individual" for "home". If needed,
>>we can add text such as "For example, they may want their employers
>>and their banks to act as trust anchor administrators."
>
>Ah, I see your point. If I can appropriately constrain the impact of
>what a TAA can do, I can safely let others be TAAs for my machine.
>That seems right for my home machine, but for a company-owned
>machine the roles probably are reversed, i.e., the employer is in
>charge and will allow the employee limited control over TAs.

Exactly right. From the TAA's point of view, there are two choices:
"I control everything in his store" and "I share control of his store
with unknown others". We don't have to choose the second way, but I
think the overhead of doing so is worth the benefit of many more
potential use cases.

>>>- Supporting devices with limited or no user interface that may or
>>>may not have connectivity to the Internet
>>>
>>>a simple typo fix, but if a deliverable is a TA management
>>>protocol, then why do we worry about devices that have no Internet
>>>connectivity?
>>
>>Protocols do not require Internet connectivity. End-to-end email is
>>a good example of that.
>
>Good point. We may want to define protocols that can use staged
>delivery, even if there is no network involved. If that's the
>intent, the bullet could be a bit clearer, e.g., if we want to
>define protocols that work even if we deliver messages via a USB
>token from a source to a destination. However, I note that a
>protocol of that sort is likely to be more complex than one that
>assumes use of lower layer network protocols, even staged delivery
>ones.

Fully disagree. We can decouple the format from how one hands the
object to the next party. This is akin to defining CMS separate from
S/MIME.

--Paul Hoffman, Director
--VPN Consortium

[Stephen Kent]

>>>...
>>
>>Good point. We may want to define protocols that can use staged
>>delivery, even if there is no network involved. If that's the
>>intent, the bullet could be a bit clearer, e.g., if we want to
>>define protocols that work even if we deliver messages via a USB
>>token from a source to a destination. However, I note that a
>>protocol of that sort is likely to be more complex than one that
>>assumes use of lower layer network protocols, even staged delivery
>>ones.
>
>Fully disagree. We can decouple the format from how one hands the
>object to the next party. This is akin to defining CMS separate from
>S/MIME.

It's not the format; it's the semantics of the underlying delivery
system. I designed and implemented this stuff a few years ago, and my
experience suggests that there is a significant difference. For
example, if I can assume network connectivity, even staged delivery,
I may be able to make assumptions about responses from a device re
delivery of data, that are less likely to be viable if a person is
moving data on a USB token.

Steve

[Turner, Sean P.]

Working on draft #2 of the charter and captured these.


_____

From: Stephen Kent [mailto:kent-A08e6c8yq/***@public.gmane.org]
Sent: Friday, August 10, 2007 4:42 PM
To: Paul Hoffman
Cc: turners-***@public.gmane.org; ietf-trust-anchor-***@public.gmane.org
Subject: Re: Draft Charter


At 1:21 PM -0700 8/10/07, Paul Hoffman wrote:

... the TAA.


- Supporting multiple trust anchor administrators, such as is typical for
home

users




Why do we believe it is common for a home user to need multiple TA
administrators?


I would be happy if we swapped "individual" for "home". If needed, we can
add text such as "For example, they may want their employers and their banks
to act as trust anchor administrators."


Ah, I see your point. If I can appropriately constrain the impact of what a
TAA can do, I can safely let others be TAAs for my machine. That seems right
for my home machine, but for a company-owned machine the roles probably are
reversed, i.e., the employer is in charge and will allow the employee
limited control over TAs.



- Supporting devices with limited or no user interface that may or may not
have connectivity to the Internet


a simple typo fix, but if a deliverable is a TA management protocol, then
why do we worry about devices that have no Internet connectivity?


Protocols do not require Internet connectivity. End-to-end email is a good
example of that.


Good point. We may want to define protocols that can use staged delivery,
even if there is no network involved. If that's the intent, the bullet
could be a bit clearer, e.g., if we want to define protocols that work even
if we deliver messages via a USB token from a source to a destination.
However, I note that a protocol of that sort is likely to be more complex
than one that assumes use of lower layer network protocols, even staged
delivery ones.

Steve

[Yoav Nir]

In Chicago there was some controversy about whether multiple
administrators should be in scope. This charter draft says that
they're in. I'm not saying they shouldn't be, but it does add
complexity.

If they're in, we need to answer big questions:
- If TAA1 adds a TA, can TAA2 delete it?
- If no, should there be "hard-delete" where it does delete it?
- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
deletes it, is it there or not?
- Should TAA2 be able to query TAs added by TAA1?
- Should we have a delete-all command (I think that's necessary for
the store-and-forward scenario)
- How does delete-all interact with multiple TAAs? Do we need a hard-
delete-all?

I would answer these questions no, yes, yes, yes, yes and yes, but
these are far from trivial.

I think these and other issues suggest we should split the TAMP
protocol deliverables into two documents: one to deal with the
protocol, formats, encoding (XML/ASN.1) and the online/offline case.
The other document should deal with trust anchor store operations:
how the database is structured and what it does with the various
commands.

Yoav


> Strawman charter for trust anchor management (tam) BoF
>
> Version: 01, July 9th 2007
>
> Chair(s)
>
> TBD
>
> Security Area Director(s):
>
> - Tim Polk <tim.polk-R3+/***@public.gmane.org>
> - Sam Hartman <hartmans-ietf-***@public.gmane.org>
>
> Security Area Advisor:
>
> TBD
>
> Mailing Lists:
>
> General Discussion: ietf-trust-anchor-***@public.gmane.org
> To Subscribe: http://www.vpnc.org/ietf-trust-anchor/
> Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/
>
> Description of Working Group:
>
> The need for a standard protocol for trust anchor management has been
> recognized for some time. Many groups within the IETF, including
> PKIX,
> Kerberos, TLS and SIDR have a dependency on trust anchors, yet
> provide no
> generic mechanism for the their management.
>
> A trust anchor is a public key and associated data used by a
> relying party to
> begin the process of validating a signature on a signed object.
> Associated data
> is used to define the scope of the use of the trust anchor for
> validating
> signatures; for example, associated data might limit the types of
> identifiers
> in certificates that a trust anchor is allowed to validate.
>
> Despite the wide-spread use of trust anchors, there is no standard
> means for
> managing these security-critical data. This Working Group will
> develop a
> specification to fill this gap.
>
> The initial problem statement for this work is to be based on:
>
> - draft-wallace-ta-mgmt-problem-statement
>
> The scope of the work is to include:
>
> <<list to be developed in Chicago>>
> - Supporting a single trust anchor administrator, such as in a typical
> enterprise, who may be administering multiple trust anchors in
> her domain,
> where those trust anchors can be either local or "foreign"
> - Supporting multiple trust anchor administrators, such as is
> typical for home
> users
> - Supporting devices with limited or no user interface that may or
> may not have
> connected to the Internet
>
> The following are out of scope of this work:
>
> <<list to be developed in Chicago>>
> - TBD
>
> The deliverables will be:
>
> - An informational problem statement/requirements specification
> for a trust anchor management protocol
> - A standards track trust anchor management protocol
> specification
>
> Goals and Milestones:
>
> +6 months WG last call on problem statement/
> requirements
> +9 months Adoption of WG draft protocol spec.
> +15 months WG last call for protocol spec.
>
>

[Paul Hoffman]

At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
>In Chicago there was some controversy about whether multiple
>administrators should be in scope. This charter draft says that
>they're in. I'm not saying they shouldn't be, but it does add
>complexity.

Indeed. But the complexity might be able to be contained with very
different assumptions than the ones you made.

>If they're in, we need to answer big questions:
>- If TAA1 adds a TA, can TAA2 delete it?
>- If no, should there be "hard-delete" where it does delete it?
>- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
>deletes it, is it there or not?
>- Should TAA2 be able to query TAs added by TAA1?
>- Should we have a delete-all command (I think that's necessary for
>the store-and-forward scenario)
>- How does delete-all interact with multiple TAAs? Do we need a
>hard-delete-all?
>
>I would answer these questions no, yes, yes, yes, yes and yes, but
>these are far from trivial.

This takes the view that the TAAs "add" and "delete" TAs. A very
different view, one that makes things a lot simpler, is that TAAs
propose additions and deletions, and the software for the recipient
of those proposals chooses whether or not to act on those proposals.
As I said at the mic in Chicago, I'm not suggesting that end users
need to think about each TAA action; they can just make policy
decisions and let the software act accordingly.

For example, assume that the user has the setting "TAA1 is more
important than TAA2". Then, in your examples:

>- If TAA1 adds a TA, can TAA2 delete it?

No.

>- If no, should there be "hard-delete" where it does delete it?

No. I would be against having various strengths of "add" and
"delete"; no one will be able to figure them out.

>- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
>deletes it, is it there or not?

It is not.

>- Should TAA2 be able to query TAs added by TAA1?

Yes. A simpler and more general mechanism is that any TAA can query
the TA store, and that store says which TAA added each TA.

>- Should we have a delete-all command (I think that's necessary for
>the store-and-forward scenario)

No. That would leave the user with no one to trust, including the
party that issued the delete-all. The TAM software should never leave
the user with no TAs except under dire circumstances.

>- How does delete-all interact with multiple TAAs? Do we need a
>hard-delete-all?

Moot; see above.

I believe that most users who have multiple TAAs could set an order
for precedence to them. I also think writing software to act on the
precedence is quite straightforward: the two rules are "only allow
delete proposals from TAAs at the same level or higher as the TAA who
added this TA" and "if a TA has been deleted, only allow it to be
re-added by a TAA at the same level or higher than the one who
deleted it".

Does this simplification seem like a good one?

--Paul Hoffman, Director
--VPN Consortium

[Yoav Nir]

Inline...

On Aug 12, 2007, at 7:55 PM, Paul Hoffman wrote:

> At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
>> In Chicago there was some controversy about whether multiple
>> administrators should be in scope. This charter draft says that
>> they're in. I'm not saying they shouldn't be, but it does add
>> complexity.
>
> Indeed. But the complexity might be able to be contained with very
> different assumptions than the ones you made.
>
<snip>
> This takes the view that the TAAs "add" and "delete" TAs. A very
> different view, one that makes things a lot simpler, is that TAAs
> propose additions and deletions, and the software for the recipient
> of those proposals chooses whether or not to act on those
> proposals. As I said at the mic in Chicago, I'm not suggesting that
> end users need to think about each TAA action; they can just make
> policy decisions and let the software act accordingly.
>

This just gave me a mental image of the next generation Internet
Explorer scary pop-up with the DN of the TAA and the DN of the new
TAA, a warning about possible exploits and data corruption, with the
final question "Do you accept this trust anchor?"

> For example, assume that the user has the setting "TAA1 is more
> important than TAA2". Then, in your examples:
>
>> - If TAA1 adds a TA, can TAA2 delete it?
>
> No.

What if TAA2 knows for a fact that the private key of the TA has been
compromised? The example I have in my head is TAA1 is Microsoft (or
Mozilla - the browser vendor), while TAA2 is your company. I can't
say that one is more important than the other.

>
>> - If no, should there be "hard-delete" where it does delete it?
>
> No. I would be against having various strengths of "add" and
> "delete"; no one will be able to figure them out.

Again, I think there should be a distinction between "I don't use
this CA any more" and "this CA is no longer trustworthy"

>
>> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
>> deletes it, is it there or not?
>
> It is not.

IMO this should depend on why TAA1 deleted it. There's a difference
between "we've switched to Verisign" and "NetLock has been compromised"

>
>> - Should TAA2 be able to query TAs added by TAA1?
>
> Yes. A simpler and more general mechanism is that any TAA can query
> the TA store, and that store says which TAA added each TA.
>
>> - Should we have a delete-all command (I think that's necessary
>> for the store-and-forward scenario)
>
> No. That would leave the user with no one to trust, including the
> party that issued the delete-all. The TAM software should never
> leave the user with no TAs except under dire circumstances.

I have two issues with this:
1. I don't think the TAM anchor should be in the same store that it
is managing. I don't even thing TAM should be administered with TAM.
2. If Microsoft (as TAA1) wants to give the users a whole new set of
anchors, it makes sense to send in a single message, a "delete-all"
command and several "add" commands. this works even better if we make
a separation between anchors added by different TAAs.

>
>> - How does delete-all interact with multiple TAAs? Do we need a
>> hard-delete-all?
>
> Moot; see above.
>
> I believe that most users who have multiple TAAs could set an order
> for precedence to them. I also think writing software to act on the
> precedence is quite straightforward: the two rules are "only allow
> delete proposals from TAAs at the same level or higher as the TAA
> who added this TA" and "if a TA has been deleted, only allow it to
> be re-added by a TAA at the same level or higher than the one who
> deleted it".
>
> Does this simplification seem like a good one?

I would rather have a system where each TAA manages the TAs that it
has added, with provisions for multiple additions and deletions. I
don't think precedence is a good simplification.

Yoav

[Paul Hoffman]

At 9:46 AM -0400 8/13/07, Stephen Kent wrote:
>You raise an important issue of perspective. If a TAA is an
>"authority" then it can try to do anything (e.g., issue any command
>in a protocol), but the effects of what it does are constrained by
>the authority granted to it. That authority may be defined by the
>user, or by some other TAA.

Exactly right. Our format/protocol gives TAAs the ability to state
what they want, but it is up to the receiving system to decide what
to do with that statement.

>However, we do need to be very careful about the complexity of
>polices that can be expressed here. We have lots of experience in
>the security environment that suggest users, even sys admins, are
>not very good at managing policies once the level of complexity
>grows beyond a certain point. Our requirements development process
>needs to be mindful of this issue, and not assume that users will
>suddenly become much better at this crucial task.

Fully agree. My view on this is that:

- We need to make the single-TAA scenario work just as expected: the
end user will follow that TAA's instructions exactly.

- We need to make the multi-TAA scenario be simple. If we do not
allow deletes, then there is problem, but I think we need to allow
deletes. Given that, we should specify the simplest way to handle
deletes.

At 4:50 PM +0300 8/13/07, Yoav Nir wrote:
>This just gave me a mental image of the next generation Internet
>Explorer scary pop-up with the DN of the TAA and the DN of the new
>TAA, a warning about possible exploits and data corruption, with the
>final question "Do you accept this trust anchor?"

If the hierarchy is defined as the user adds TAAs, then no such
interaction is ever needed. I understand your desire for the
single-TAA model, but please don't say that the multi-TAA model is
more complicated than it needs to be.

>>For example, assume that the user has the setting "TAA1 is more
>>important than TAA2". Then, in your examples:
>>
>>>- If TAA1 adds a TA, can TAA2 delete it?
>>
>>No.
>
>What if TAA2 knows for a fact that the private key of the TA has
>been compromised? The example I have in my head is TAA1 is
>Microsoft (or Mozilla - the browser vendor), while TAA2 is your
>company. I can't say that one is more important than the other.

If you cannot create a hierarchy, then you are forcing the user to
make decisions for every addition or removal of any TA. There was
strong pushback against that in Chicago. That leaves us with two
options: go with the single-TAA model, or go with a multi-TAA model
that does not require user interaction when new TAs are added or
current TAs are removed. I favor the latter.

--Paul Hoffman, Director
--VPN Consortium

[Cat Okita]

On Mon, 13 Aug 2007, Yoav Nir wrote:
>> I believe that most users who have multiple TAAs could set an order for
>> precedence to them. I also think writing software to act on the precedence
>> is quite straightforward: the two rules are "only allow delete proposals
>> from TAAs at the same level or higher as the TAA who added this TA" and "if
>> a TA has been deleted, only allow it to be re-added by a TAA at the same
>> level or higher than the one who deleted it".
>>
>> Does this simplification seem like a good one?
>
> I would rather have a system where each TAA manages the TAs that it has
> added, with provisions for multiple additions and deletions. I don't think
> precedence is a good simplification.

I agree - precedence is a poor simplification, especially if we encounter
cases where differing precedence is desired (eg: precedence for web
trust varies according to the site being contacted).

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet. This is the defining metaphor of my life right now."

[Stephen Kent]

>>...
>
>This takes the view that the TAAs "add" and "delete" TAs. A very
>different view, one that makes things a lot simpler, is that TAAs
>propose additions and deletions, and the software for the recipient
>of those proposals chooses whether or not to act on those proposals.
>As I said at the mic in Chicago, I'm not suggesting that end users
>need to think about each TAA action; they can just make policy
>decisions and let the software act accordingly.

You raise an important issue of perspective. If a TAA is an
"authority" then it can try to do anything (e.g., issue any command
in a protocol), but the effects of what it does are constrained by
the authority granted to it. That authority may be defined by the
user, or by some other TAA.

However, we do need to be very careful about the complexity of
polices that can be expressed here. We have lots of experience in
the security environment that suggest users, even sys admins, are not
very good at managing policies once the level of complexity grows
beyond a certain point. Our requirements development process needs
to be mindful of this issue, and not assume that users will suddenly
become much better at this crucial task.

Steve

[Leif Johansson]

Yoav Nir wrote:
>
> In Chicago there was some controversy about whether multiple
> administrators should be in scope. This charter draft says that
> they're in. I'm not saying they shouldn't be, but it does add complexity.
>

Multiple admins would seem to imply the need for a standardized way
to express access policy. Whenever the 'P-word' turns up I get nervous
since there aren't a lot of _good_ examples of standardized policy-
language. From the questions you list it sounds to me like the policy/aci
language for trust-stores could be about as complex as that of any
directory. Say you want to control access to the attributes associated
with a trust anchor for instance - that would immediately suck in the
whole mess of directory aci:s by reference.

All of this can be done of course but it probably helps to jump into that
hole with eyes open ;-)

Cheers Leif

[Stephen Kent]

At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
>In Chicago there was some controversy about whether multiple
>administrators should be in scope. This charter draft says that
>they're in. I'm not saying they shouldn't be, but it does add
>complexity.
>
>If they're in, we need to answer big questions:
>- If TAA1 adds a TA, can TAA2 delete it?

if we allow creating a hierarchy )or even a lattice) of TAAs, then
once cannot answer this question without knowing the relationships of
TAA1 and TAA2.

>- If no, should there be "hard-delete" where it does delete it?

define "hard delete"

>- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
>deletes it, is it there or not?

this already presumes that the addition you mention is idempotent,
somethign we have yet to deciude.

>- Should TAA2 be able to query TAs added by TAA1?
>- Should we have a delete-all command (I think that's necessary for
>the store-and-forward scenario)
>- How does delete-all interact with multiple TAAs? Do we need a
>hard-delete-all?
>
>I would answer these questions no, yes, yes, yes, yes and yes, but
>these are far from trivial.
>
>I think these and other issues suggest we should split the TAMP
>protocol deliverables into two documents: one to deal with the
>protocol, formats, encoding (XML/ASN.1) and the online/offline case.
>The other document should deal with trust anchor store operations:
>how the database is structured and what it does with the various
>commands.
>
>Yoav

how about one to agree on the requirements first :-), before we
define the syntax and semantics?

Steve

[Yoav Nir]

On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote:

> At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
>> In Chicago there was some controversy about whether multiple
>> administrators should be in scope. This charter draft says that
>> they're in. I'm not saying they shouldn't be, but it does add
>> complexity.
>>
>> If they're in, we need to answer big questions:
>> - If TAA1 adds a TA, can TAA2 delete it?
>
> if we allow creating a hierarchy )or even a lattice) of TAAs, then
> once cannot answer this question without knowing the relationships
> of TAA1 and TAA2.

So our protocol document (or operations document) will need to define
such relationships
>
>> - If no, should there be "hard-delete" where it does delete it?
>
> define "hard delete"

Delete even though this TA was added by another TAA. This does
assume that TAAs only manage the TAs they added.
>
>> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
>> deletes it, is it there or not?
>
> this already presumes that the addition you mention is idempotent,
> somethign we have yet to deciude.

Of course. I'm just enumerating several possible complexities off the
top of my head.
>
>> - Should TAA2 be able to query TAs added by TAA1?
>> - Should we have a delete-all command (I think that's necessary
>> for the store-and-forward scenario)
>> - How does delete-all interact with multiple TAAs? Do we need a
>> hard-delete-all?
>>
>> I would answer these questions no, yes, yes, yes, yes and yes, but
>> these are far from trivial.
>>
>> I think these and other issues suggest we should split the TAMP
>> protocol deliverables into two documents: one to deal with the
>> protocol, formats, encoding (XML/ASN.1) and the online/offline case.
>> The other document should deal with trust anchor store operations:
>> how the database is structured and what it does with the various
>> commands.
>>
>> Yoav
>
> how about one to agree on the requirements first :-), before we
> define the syntax and semantics?
>
> Steve
>

[Stephen Kent]

At 4:55 PM +0300 8/13/07, Yoav Nir wrote:
>On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote:
>
>>At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
>>>In Chicago there was some controversy about whether multiple
>>>administrators should be in scope. This charter draft says that
>>>they're in. I'm not saying they shouldn't be, but it does add
>>>complexity.
>>>
>>>If they're in, we need to answer big questions:
>>>- If TAA1 adds a TA, can TAA2 delete it?
>>
>>if we allow creating a hierarchy )or even a lattice) of TAAs, then
>>once cannot answer this question without knowing the relationships
>>of TAA1 and TAA2.
>
>So our protocol document (or operations document) will need to
>define such relationships

yes.

>>
>>>- If no, should there be "hard-delete" where it does delete it?
>>
>>define "hard delete"
>
>Delete even though this TA was added by another TAA. This does
>assume that TAAs only manage the TAs they added.

perhaps a simpler model is to allow a delete by a TAA if the TAA is
authorized to delete the TA, period.

Steve

[Thomas Hardjono]

> -----Original Message-----
> From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Yoav Nir
> Sent: Monday, August 13, 2007 6:55 AM
> To: Stephen Kent
> Cc: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
>
> On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote:
>
> > At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
> >> In Chicago there was some controversy about whether multiple
> >> administrators should be in scope. This charter draft says that
> >> they're in. I'm not saying they shouldn't be, but it does add
> >> complexity.
> >>
> >> If they're in, we need to answer big questions:
> >> - If TAA1 adds a TA, can TAA2 delete it?
> >
> > if we allow creating a hierarchy )or even a lattice) of TAAs, then
> > once cannot answer this question without knowing the
> relationships of
> > TAA1 and TAA2.
>
> So our protocol document (or operations document) will need
> to define such relationships
> >
> >> - If no, should there be "hard-delete" where it does delete it?
> >
> > define "hard delete"
>
> Delete even though this TA was added by another TAA. This
> does assume that TAAs only manage the TAs they added.
> >
> >> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1
> >> deletes it, is it there or not?
> >
> > this already presumes that the addition you mention is idempotent,
> > somethign we have yet to deciude.
>
> Of course. I'm just enumerating several possible complexities
> off the top of my head.
> >
> >> - Should TAA2 be able to query TAs added by TAA1?
> >> - Should we have a delete-all command (I think that's
> necessary for
> >> the store-and-forward scenario)
> >> - How does delete-all interact with multiple TAAs? Do we need a
> >> hard-delete-all?
> >>
> >> I would answer these questions no, yes, yes, yes, yes and yes, but
> >> these are far from trivial.
> >>
> >> I think these and other issues suggest we should split the TAMP
> >> protocol deliverables into two documents: one to deal with the
> >> protocol, formats, encoding (XML/ASN.1) and the
> online/offline case.
> >> The other document should deal with trust anchor store
> operations:
> >> how the database is structured and what it does with the various
> >> commands.
> >>
> >> Yoav
> >
> > how about one to agree on the requirements first :-),
> before we define
> > the syntax and semantics?
> >
> > Steve

With regards to the thread on multiple TA-Authorities (TAA), this is why
I was a bit insistent earlier that we focus initially on the Enterprise
environment (since its easier).

Within the Enterprise there is typically a single TAA (eg. IT admin),
and she/he will be the entity doing the adding/deleting of all Trust
Anchors for all the machines & devices within the Enterprise. (PS. I'm
assuming here that commands to install/delete TAs will be accompanied by
the appropriate source authentication).

In the Consumer space, TA usage and management may have to be
application-driven. Meaning that if an organization (e.g. Bank,
SalesForce.com, etc) requires its TA to be present at the client
end-point before allowing a transaction, then the home-user will just
have to accept such installation (ie. press "Yes" at the dialog box).
If a Bank's TA is inadvertently deleted (eg. by a user, malware or
another TA), then the Bank will just have to install it again the next
time the user seeks to transact with the Bank.

If a virus or malware succeeds in deleting or modifying TAs at a
consumer machine, well the consumer will simply have to (somehow)
install them back agaian (eg. from backup).

/thomas/

[Yoav Nir]

On Aug 14, 2007, at 2:48 AM, Thomas Hardjono wrote:
<snip>
>
> With regards to the thread on multiple TA-Authorities (TAA), this
> is why
> I was a bit insistent earlier that we focus initially on the
> Enterprise
> environment (since its easier).
>
> Within the Enterprise there is typically a single TAA (eg. IT admin),
> and she/he will be the entity doing the adding/deleting of all Trust
> Anchors for all the machines & devices within the Enterprise. (PS. I'm
> assuming here that commands to install/delete TAs will be
> accompanied by
> the appropriate source authentication).
>
> In the Consumer space, TA usage and management may have to be
> application-driven. Meaning that if an organization (e.g. Bank,
> SalesForce.com, etc) requires its TA to be present at the client
> end-point before allowing a transaction, then the home-user will just
> have to accept such installation (ie. press "Yes" at the dialog box).
> If a Bank's TA is inadvertently deleted (eg. by a user, malware or
> another TA), then the Bank will just have to install it again the next
> time the user seeks to transact with the Bank.
>
> If a virus or malware succeeds in deleting or modifying TAs at a
> consumer machine, well the consumer will simply have to (somehow)
> install them back agaian (eg. from backup).
>
> /thomas/

I think what's typical for an Enterprise depends on the application.
If we're talking about browsers, then I think it's perfectly
acceptable to have two TAAs - one from the browser vendor (it
shouldn't be my employer's task to tell me that Verisign has a new
root CA certificate - that's Microsoft's job) and the other being the
corporate IT department. That's why I think each TAA should be able
to manage its own (and only its own) trust anchors.

In your consumer space example, I again don't think SalesForce.com
should be able to delete bankofamerica.com's trust anchor. Perhaps
there should be exception, such as if Microsoft learns that the
bankofamerica.com TA really belongs to a phishing company, but I
think each TAA should manage its own as a general rule, and this
should be enforced.

[Stephen Kent]

>...
>I think what's typical for an Enterprise depends on the application.
>If we're talking about browsers, then I think it's perfectly
>acceptable to have two TAAs - one from the browser vendor (it
>shouldn't be my employer's task to tell me that Verisign has a new
>root CA certificate - that's Microsoft's job) and the other being
>the corporate IT department. That's why I think each TAA should be
>able to manage its own (and only its own) trust anchors.

Even in this case I can see problems, I think several folks have
noted that the default TAs currently installed in browsers ought to
be subject to local management, especially deletion! So, as a browser
user in an enterprise context, I would not want a TAA installed by MS
(or, in my case, Apple) to be able to maintain the presence of TAs
even if my IT dept wants to remove them.

>In your consumer space example, I again don't think SalesForce.com
>should be able to delete bankofamerica.com's trust anchor. Perhaps
>there should be exception, such as if Microsoft learns that the
>bankofamerica.com TA really belongs to a phishing company, but I
>think each TAA should manage its own as a general rule, and this
>should be enforced.

This example seems to suggest that a home user might have lots of
TAAs, not just a lot of TAs. I'd worry that the result would be
unmanageable for most home users. Did I misunderstand your example?

Steve

[Cat Okita]

On Thu, 16 Aug 2007, Stephen Kent wrote:
>> I think what's typical for an Enterprise depends on the application. If
>> we're talking about browsers, then I think it's perfectly acceptable to
>> have two TAAs - one from the browser vendor (it shouldn't be my employer's
>> task to tell me that Verisign has a new root CA certificate - that's
>> Microsoft's job) and the other being the corporate IT department. That's
>> why I think each TAA should be able to manage its own (and only its own)
>> trust anchors.
>
> Even in this case I can see problems, I think several folks have noted that
> the default TAs currently installed in browsers ought to be subject to local
> management, especially deletion! So, as a browser user in an enterprise
> context, I would not want a TAA installed by MS (or, in my case, Apple) to be
> able to maintain the presence of TAs even if my IT dept wants to remove them.

Agreed - we've already discussed the current problem of unwanted TAs being
silently put back into browsers. It's also much easier to move from a
point of less privledge to granting more, rather than the other way around.

>> In your consumer space example, I again don't think SalesForce.com should
>> be able to delete bankofamerica.com's trust anchor. Perhaps there should be
>> exception, such as if Microsoft learns that the bankofamerica.com TA really
>> belongs to a phishing company, but I think each TAA should manage its own
>> as a general rule, and this should be enforced.
>
> This example seems to suggest that a home user might have lots of TAAs, not
> just a lot of TAs. I'd worry that the result would be unmanageable for most
> home users. Did I misunderstand your example?

If I recall correctly, the expectation was that home users might have
lots of TAAs, but the likely situation would be that they'd take a
default trust set, and only dive down into the fine bits in a limited
number of circumstances (namely users like us...)

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet. This is the defining metaphor of my life right now."

[Stephen Kent]

At 11:49 AM -0400 8/16/07, Cat Okita wrote:
>>...
>>This example seems to suggest that a home user might have lots of
>>TAAs, not just a lot of TAs. I'd worry that the result would be
>>unmanageable for most home users. Did I misunderstand your example?
>
>If I recall correctly, the expectation was that home users might
>have lots of TAAs, but the likely situation would be that they'd
>take a
>default trust set, and only dive down into the fine bits in a limited
>number of circumstances (namely users like us...)

I'm not sure that we agree on this. The current situation is that
there is one TAA (typically the browser vendor) and a lot of TAs. One
might say that a browser vendor would install all the current TAs as
TAAs, but there is no a priori reason to assume that model.

Steve

[Seppo Lindborg (JO/LMF)]

This the current situation, but is it OK, or even acceptable? Wouldn't
it be more appropriate approach that there were no ready trust
assumptions or settings in the tool, and the user would add his, either
from some ready file, or case-by-case when he surfs?

Seppo Lindborg

> -----Original Message-----
> From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of
> Stephen Kent
> Sent: 16. elokuuta 2007 19:25
> To: Cat Okita
> Cc: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
> I'm not sure that we agree on this. The current situation is
> that there is one TAA (typically the browser vendor) and a
> lot of TAs. One might say that a browser vendor would install
> all the current TAs as TAAs, but there is no a priori reason
> to assume that model.
>
> Steve
>
>

[Stephen Kent]

At 9:18 AM +0200 8/17/07, Seppo Lindborg (JO/LMF) wrote:
>This the current situation, but is it OK, or even acceptable? Wouldn't
>it be more appropriate approach that there were no ready trust
>assumptions or settings in the tool, and the user would add his, either
>from some ready file, or case-by-case when he surfs?
>
>Seppo Lindborg

For some, sophisticated users this could be a great improvement. For
99% of the users it would likely create more opportunities for social
engineering. We have years of experience, plus a nice study by folks
at CMU, showing that the average user is clueless about SSL/TLS, lock
icons, etc. and is easily fooled. That's why phishing is so
successful.

Steve

[B***@public.gmane.org]

I want to expand on something I said at the microphone in Chicago -

I think the easiest (and likely to be the most common) solution to
multiple TAAs that don't have the same management privileges is
separate trust anchor stores and that an operational model of all
TAAs for a trust anchor store having the same management privileges
is the easiest to cope with. I think any use case that postulates
different TAAs with different privileges for the *same* trust anchor
store needs to have a strong justification for the difference in
privileges. Let me start by applying this to Yoav's enterprise
browser example:

> >I think what's typical for an Enterprise depends on the application.
> >If we're talking about browsers, then I think it's perfectly
> >acceptable to have two TAAs - one from the browser vendor (it
> >shouldn't be my employer's task to tell me that Verisign has a new
> >root CA certificate - that's Microsoft's job) and the other being
> >the corporate IT department. That's why I think each TAA should be
> >able to manage its own (and only its own) trust anchors.
>
> Even in this case I can see problems, I think several folks have
> noted that the default TAs currently installed in browsers ought to
> be subject to local management, especially deletion! So, as a browser
> user in an enterprise context, I would not want a TAA installed by MS
> (or, in my case, Apple) to be able to maintain the presence of TAs
> even if my IT dept wants to remove them.

I agree with Steve, and my employer behaves in exactly this way with
respect to *all* MS updates, not just browser trust anchors - all of
MS's automatic updates flow through a server maintained by the corporate
IT folks, hence there's only one TAA. I do not see the need for
multiple TAAs with different privileges - either the IT folks trust
MS to do whatever MS wants to (both TAAs have the same privileges)
or they don't (MS updates redirected through IT, IT is the only TAA).

> >In your consumer space example, I again don't think SalesForce.com
> >should be able to delete bankofamerica.com's trust anchor. Perhaps
> >there should be exception, such as if Microsoft learns that the
> >bankofamerica.com TA really belongs to a phishing company, but I
> >think each TAA should manage its own as a general rule, and this
> >should be enforced.

If SalesForce.com needs to manage browser trust anchors, then it needs
its own trust anchor store (perhaps even its own copy of the browser)
on the end user's system, and then SalesForce.com can do whatever it
wants with those anchors. I suspect SalesForce.com is unlikely to
want to do this, and probably has limited in managing trust anchors
of its customers/users, as it's very easy to break things this way.
One specific point is that trust anchor changes don't strike me as
a good way to deal with phishing - encouraging or forcing an updated
CRL into the browser before allowing site access is likely to be
considerably more effective.

My preference is that managing different privileges for multiple
TAAs administering the same trust anchor store ought to be out of
scope, unless someone has a compelling use case with which to argue
otherwise.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david-***@public.gmane.org Mobile: [phone]
----------------------------------------------------

[Russ Housley]

David:

I think we need to think about the degree of delegation that we want
to permit. I can imagine an enterprise permitting a contracted
service to provide some support here. However, the one thing that
the do not want the contracted service to do is remove the enterprise
from the picture. That would prevent the enterprise from changing providers.

So, I can imagine the enterprise holding an all-powerful TA, and
using this to add and delete TA administration privileges for the
trust anchor stores in the devices and software packages that are
used in the enterprise. The TA administration privilege must not be
sufficient to become the all-powerful TA. I see no reason for there
to me more than one all-powerful TA as long as the all-powerful TA
can be used to make updates to the all-powerful TA, say when two
enterprises merge.

Russ

At 12:11 PM 8/17/2007, Black_David-***@public.gmane.org wrote:
>My preference is that managing different privileges for multiple
>TAAs administering the same trust anchor store ought to be out of
>scope, unless someone has a compelling use case with which to argue
>otherwise.

[B***@public.gmane.org]

Russ,

> At 12:11 PM 8/17/2007, Black_David-***@public.gmane.org wrote:
> >My preference is that managing different privileges for multiple
> >TAAs administering the same trust anchor store ought to be out of
> >scope, unless someone has a compelling use case with which to argue
> >otherwise.
>
> I think we need to think about the degree of delegation that we want
> to permit. I can imagine an enterprise permitting a contracted
> service to provide some support here. However, the one thing that
> the do not want the contracted service to do is remove the enterprise
> from the picture. That would prevent the enterprise from changing
> providers.

I definitely agree that we need to think about delegation - IMHO,
delegation is second only to policy in its ability to introduce
complexities, subtleties and the concomitant opportunity for
implementation and user mistakes that cause security issues in
practice.

> So, I can imagine the enterprise holding an all-powerful TA, and
> using this to add and delete TA administration privileges for the
> trust anchor stores in the devices and software packages that are
> used in the enterprise. The TA administration privilege must not
> be sufficient to become the all-powerful TA.

All of the TAs in the above paragraph are the anchors for the trust
stores which in turn contain trust anchors for use by applications.

For clarity, let's use the term Trust Store Anchor (TSA) to refer
to an anchor that confers the ability to manage application trust
anchors in a trust store, and use the term Application Trust Anchors
(ATAs) if/as necessary for clarity.

Using this terminology, the scenario that Russ is concerned about
boils down to controlling which TSAs can manage the TSAs for a trust
store. Both TSAs can manage all the application TAs, as the enterprise
presumably trusts the contracted service to correctly manage the
enterprise-specific ATAs (and if the enterprise doesn't, I strongly
suggest that it should resort to the "send all your updates through
me" solution described for Microsoft updates in earlier messages).

I think it would be fine for every TSA entry in a trust store to have
a boolean property indicating whether it can manage the TSAs for the
trust store, as long as all the TSAs for a trust store can manage
all of the application trust anchors in that trust store.

Given all of this, Russ's issue is then how the enterprise retains
control over its trust stores (e.g., so it can switch to another
trust anchor management service provider without the existing provider's
cooperation). With the "can manage TSAs" boolean property, the solution
is reasonably straightforward - each trust store has two Trust Store
Anchors:
- The (all-powerful) enterprise TSA with its "can manage TSAs"
property set to True.
- The contracted service TSA with its "can manage TSAs"
property set to False.
Both TSAs can manage all the application trust anchors in the trust
store, and if a (contractual) conflict arises, the enterprise TSA is
used to delete the contracted service TSA and clean up whatever mess
it left behind.

One more item. Russ wrote:

> I see no reason for there to me more than one all-powerful TA as
> long as the all-powerful TA can be used to make updates to the
> all-powerful TA, say when two enterprises merge.

The reason may be dealing with private key compromise in a tractable
fashion - if an all-powerful TA needs to be revoked (e.g., via a CRL),
it would be more than convenient to have another one to use. Two
should be enough.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david-***@public.gmane.org Mobile: [phone]
----------------------------------------------------

[Russ Housley]

David:

I think we have reached agreement on the vast bulk of the things in
my message and your reply.

One exception:

>One more item. Russ wrote:
>
> > I see no reason for there to me more than one all-powerful TA as
> > long as the all-powerful TA can be used to make updates to the
> > all-powerful TA, say when two enterprises merge.
>
>The reason may be dealing with private key compromise in a tractable
>fashion - if an all-powerful TA needs to be revoked (e.g., via a CRL),
>it would be more than convenient to have another one to use. Two
>should be enough.

You cannot deal with trust anchor compromise with CRLs. Trust
anchors represent the beginning of a certification path, and thus
they do not have a parent to issue the CRL.

I agree that trust anchor compromise deserves some attention. SET
offered a solution, which may be covered by a patent held by VISA
International. I am aware of at least one other solution, but it is
not clear if a patent is in the works or not. I'm trying to find out.

Russ

[Yoav Nir]

I, for one, don't have a compelling case. I think the enterprise has
the browser TA store holding exactly Microsoft's (or Apple's or
Mozilla's) regular store plus one more enterprise TA. Maybe there
could be two extra TAs right after a merger. What Stephen Kent
suggested, that the IT department appoint itself as the one and only
TAA and then repeat all of Microsoft's changes, may be the way
enterprises choose to handle this (either that or outsourcing it like
all other IT). but then you don't need multiple TAAs at all. You may
want to allow them for high availability and such, but they're all
the same.

To get a real requirement for separation of powers or for a hierarchy
of authority, we'll need to look for an example where the computer,
or more specifically - the application associated with the TA store
(TAS?) is somehow controlled by more than one entity. The example
where a bank requires you to allow it to manage your browser sounds
forced to me. Real banks would like you to connect from anywhere, so
they'll buy a certificate from one of the >100 TA vendors that
everybody's got in their browser.

Someone suggested an example of a contractor or consultant who works
for several companies such as in the enterprise example, so she needs
to have each IT department as TAA. I'm not sure I buy this either,
but it could be.

Perhaps one of the non-browser examples might have a more compelling
case?


On Aug 17, 2007, at 7:11 PM, Black_David-***@public.gmane.org wrote:

>
> My preference is that managing different privileges for multiple
> TAAs administering the same trust anchor store ought to be out of
> scope, unless someone has a compelling use case with which to argue
> otherwise.

[Stephen Kent]

David,

I agree that if multiple TAAs are completely independent of one
another, the simplest approach is to treat the stores as independent.

Complexity arises when different TAAs are not completely independent.
If there are relationships among TAAs, then we have to be able to
express the relationships. This can be quite hard, depending of what
range of relationships we agree need to be supported.

Moreover, if the relationships are expressed via data in the TAs
themselves, then we get into the situation I have alluded to before,
and for which Leif has asked me for concrete examples.

See my message to Paul for an example.

Steve

[Carl Wallace]

> I believe that most users who have multiple TAAs could set an
> order for precedence to them. I also think writing software
> to act on the precedence is quite straightforward: the two
> rules are "only allow delete proposals from TAAs at the same
> level or higher as the TAA who added this TA" and "if a TA
> has been deleted, only allow it to be re-added by a TAA at
> the same level or higher than the one who deleted it".
>
> Does this simplification seem like a good one?

I'd prefer to see support for rules based on TAA capabilities vs. admin
precedence. For example, in PKIX, things like name constraints or usage
constraints could be used. Rules based on values like these may be more
applicable to enterprise scenarios with a precedence system being easier for
individual users. It'd be easy to define precedence using an extension-like
mechanism similar to name constraints and usage constraints.

[Paul Hoffman]

At 1:38 PM -0400 8/12/07, Carl Wallace wrote:
>I'd prefer to see support for rules based on TAA capabilities vs.
>admin precedence. For example, in PKIX, things like name
>constraints or usage constraints could be used. Rules based on
>values like these may be more applicable to enterprise scenarios
>with a precedence system being easier for individual users. It'd be
>easy to define precedence using an extension-like mechanism similar
>to name constraints and usage constraints.

It sounds like your TAA capabilities would map fairly directly to a
precedence. That seems fine too.

--Paul Hoffman, Director
--VPN Consortium

[Carl Wallace]

> perhaps a simpler model is to allow a delete by a TAA if the
> TAA is authorized to delete the TA, period.
>

This seems like the right rule to me. The TAA that added a particular TA
need not be considered at deletion time.

[Carl Wallace]

<snip>
> > At 12:11 PM 8/17/2007, Black_David-***@public.gmane.org wrote:
> > >My preference is that managing different privileges for
> multiple TAAs
> > >administering the same trust anchor store ought to be out
> of scope,
> > >unless someone has a compelling use case with which to argue
> > >otherwise.

Requiring separate trust stores to accommodate multiple trust anchor
managers with different privileges is one approach, but it might not be the
easiest to manage. Depending on how it is supported, routine rekey may be
one example for allowing multiple TAAs with different privileges. For
example, a TA that is authoritative for namespace X could generate a
management message that could be used to add its new key to a trust store
and remove its old key. Assuming the trust store has multiple TAs for
different namespaces, there would be multiple TAAs with different
privileges.

<snip>
> > So, I can imagine the enterprise holding an all-powerful
> TA, and using
> > this to add and delete TA administration privileges for the trust
> > anchor stores in the devices and software packages that are used in
> > the enterprise. The TA administration privilege must not be
> > sufficient to become the all-powerful TA.
>
> All of the TAs in the above paragraph are the anchors for the
> trust stores which in turn contain trust anchors for use by
> applications.
>
> For clarity, let's use the term Trust Store Anchor (TSA) to
> refer to an anchor that confers the ability to manage
> application trust anchors in a trust store, and use the term
> Application Trust Anchors
> (ATAs) if/as necessary for clarity.
>
> Using this terminology, the scenario that Russ is concerned
> about boils down to controlling which TSAs can manage the
> TSAs for a trust store. Both TSAs can manage all the
> application TAs, as the enterprise presumably trusts the
> contracted service to correctly manage the
> enterprise-specific ATAs (and if the enterprise doesn't, I
> strongly suggest that it should resort to the "send all your
> updates through me" solution described for Microsoft updates
> in earlier messages).

Why limit the arrangement such that the contracted service can manage
everything? It doesn't seem like much of a stretch to use constraints
similar to those we've discussed for application TAs, i.e., name constraints
or usage constraints.

<snip>
> One more item. Russ wrote:
>
> > I see no reason for there to me more than one all-powerful
> TA as long
> > as the all-powerful TA can be used to make updates to the
> all-powerful
> > TA, say when two enterprises merge.
>
> The reason may be dealing with private key compromise in a
> tractable fashion - if an all-powerful TA needs to be revoked
> (e.g., via a CRL), it would be more than convenient to have
> another one to use. Two should be enough.

This suggests we need to be able to represent: a pair all powerful TSAs, if
for no other reason than recovery from compromise or loss; one or more(?)
less-powerful TSAs; and a set of ATAs.

[B***@public.gmane.org]

Carl,

> Why limit the arrangement such that the contracted service can manage
everything?

Why not? In particular, I see profound contractual difficulties if the
enterprise
can't trust the contracted service to manage all the trust anchors - if
it's not
trusted for that, what else is it not trusted for, and how are we going
to express
that?

> It doesn't seem like much of a stretch to use constraints similar to
those we've
> discussed for application TAs, i.e., name constraints or usage
constraints.

The proverbial road to <bleep> (complexity) is paved with exactly these
sorts of
good intentions (e.g., "nice to have" features). The moment TSAs have
to be
configured with name and usage constraints, the administrative problems
of managing
trust anchor management have gone up significantly (the trust anchors
are already
hard enough to manage - we should strive to avoid making that problem
significantly
worse). I'm interested in "must have" arguments, but my response to
"nice to have"
arguments about features for managing trust anchor management is going
to be to
complain (whine if necessary) about administrative complexity - i.e., if
in doubt,
leave it out. I have use cases in mind in which this is used by
non-security-
experts (i.e., people trying to accomplish something else) to centralize
trust
anchor management - I don't want this "cure" to be worse than the
"disease".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david-***@public.gmane.org Mobile: [phone]
----------------------------------------------------

________________________________

From: Carl Wallace [mailto:CWallace-hL1uZWTJ99NWk0Htik3J/***@public.gmane.org]
Sent: Saturday, August 18, 2007 2:36 PM
To: housley-Ib7fgPhUa/pWk0Htik3J/***@public.gmane.org; Black, David
Cc: ietf-trust-anchor-***@public.gmane.org
Subject: RE: Multiple TAAs




<snip>
> > At 12:11 PM 8/17/2007, Black_David-***@public.gmane.org wrote:
> > >My preference is that managing different privileges for
> multiple TAAs
> > >administering the same trust anchor store ought to be out
> of scope,
> > >unless someone has a compelling use case with which to
argue
> > >otherwise.

Requiring separate trust stores to accommodate multiple trust
anchor managers with different privileges is one approach, but it might
not be the easiest to manage. Depending on how it is supported, routine
rekey may be one example for allowing multiple TAAs with different
privileges. For example, a TA that is authoritative for namespace X
could generate a management message that could be used to add its new
key to a trust store and remove its old key. Assuming the trust store
has multiple TAs for different namespaces, there would be multiple TAAs
with different privileges.

<snip>
> > So, I can imagine the enterprise holding an all-powerful
> TA, and using
> > this to add and delete TA administration privileges for the
trust
> > anchor stores in the devices and software packages that are
used in
> > the enterprise. The TA administration privilege must not be

> > sufficient to become the all-powerful TA.
>
> All of the TAs in the above paragraph are the anchors for the
> trust stores which in turn contain trust anchors for use by
> applications.
>
> For clarity, let's use the term Trust Store Anchor (TSA) to
> refer to an anchor that confers the ability to manage
> application trust anchors in a trust store, and use the term
> Application Trust Anchors
> (ATAs) if/as necessary for clarity.
>
> Using this terminology, the scenario that Russ is concerned
> about boils down to controlling which TSAs can manage the
> TSAs for a trust store. Both TSAs can manage all the
> application TAs, as the enterprise presumably trusts the
> contracted service to correctly manage the
> enterprise-specific ATAs (and if the enterprise doesn't, I
> strongly suggest that it should resort to the "send all your
> updates through me" solution described for Microsoft updates
> in earlier messages).

Why limit the arrangement such that the contracted service can
manage everything? It doesn't seem like much of a stretch to use
constraints similar to those we've discussed for application TAs, i.e.,
name constraints or usage constraints.


<snip>
> One more item. Russ wrote:
>
> > I see no reason for there to me more than one all-powerful
> TA as long
> > as the all-powerful TA can be used to make updates to the
> all-powerful
> > TA, say when two enterprises merge.
>
> The reason may be dealing with private key compromise in a
> tractable fashion - if an all-powerful TA needs to be revoked
> (e.g., via a CRL), it would be more than convenient to have
> another one to use. Two should be enough.

This suggests we need to be able to represent: a pair all
powerful TSAs, if for no other reason than recovery from compromise or
loss; one or more(?) less-powerful TSAs; and a set of ATAs.

[Russ Housley]

<html>
<body>
I strongly support Carl's point.&nbsp; In performing delegation, it might
be very useful to apply limits to the delegation.&nbsp; X.509 already has
a very good set of certification path validation constraints that will
work nicely.&nbsp; However, there seems to be one missing in this
context.&nbsp; It would be very useful to constrain the applications that
the delegated-to trust anchor could impact.<br><br>
Russ<br><br>
Carl Wallace wrote:<br><br>
<blockquote type=cite class=cite cite=""><font size=2>&nbsp;</font> <br>
<font size=2>&lt;snip&gt;</font> <br>
<font size=2>&gt; &gt; At 12:11 PM 8/17/2007, Black_David-***@public.gmane.org
wrote:</font> <br>
<font size=2>&gt; &gt; &gt;My preference is that managing different
privileges for </font><br>
<font size=2>&gt; multiple TAAs </font><br>
<font size=2>&gt; &gt; &gt;administering the same trust anchor store
ought to be out </font><br>
<font size=2>&gt; of scope, </font><br>
<font size=2>&gt; &gt; &gt;unless someone has a compelling use case with
which to argue </font><br>
<font size=2>&gt; &gt; &gt;otherwise.</font> <br><br>
<font size=2>Requiring separate trust stores to accommodate multiple
trust anchor managers with different privileges is one approach, but it
might not be the easiest to manage.&nbsp; Depending on how it is
supported, routine rekey may be one example for allowing multiple TAAs
with different privileges.&nbsp; For example, a TA that is authoritative
for namespace X could generate a management message that could be used to
add its new key to a trust store and remove its old key.&nbsp; Assuming
the trust store has multiple TAs for different namespaces, there would be
multiple TAAs with different privileges.<br>
</font><br>
<font size=2>&lt;snip&gt;</font> <br>
<font size=2>&gt; &gt; So, I can imagine the enterprise holding an
all-powerful </font><br>
<font size=2>&gt; TA, and using </font><br>
<font size=2>&gt; &gt; this to add and delete TA administration
privileges for the trust </font><br>
<font size=2>&gt; &gt; anchor stores in the devices and software packages
that are used in </font><br>
<font size=2>&gt; &gt; the enterprise.&nbsp; The TA administration
privilege must not be </font><br>
<font size=2>&gt; &gt; sufficient to become the all-powerful TA.</font>
<br>
<font size=2>&gt; </font><br>
<font size=2>&gt; All of the TAs in the above paragraph are the anchors
for the </font><br>
<font size=2>&gt; trust stores which in turn contain trust anchors for
use by </font><br>
<font size=2>&gt; applications.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; For clarity, let's use the term Trust Store Anchor
(TSA) to </font><br>
<font size=2>&gt; refer to an anchor that confers the ability to manage
</font><br>
<font size=2>&gt; application trust anchors in a trust store, and use the
term </font><br>
<font size=2>&gt; Application Trust Anchors</font> <br>
<font size=2>&gt; (ATAs) if/as necessary for clarity.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Using this terminology, the scenario that Russ is
concerned </font><br>
<font size=2>&gt; about boils down to controlling which TSAs can manage
the </font><br>
<font size=2>&gt; TSAs for a trust store.&nbsp; Both TSAs can manage all
the </font><br>
<font size=2>&gt; application TAs, as the enterprise presumably trusts
the </font><br>
<font size=2>&gt; contracted service to correctly manage the </font><br>
<font size=2>&gt; enterprise-specific ATAs (and if the enterprise
doesn't, I </font><br>
<font size=2>&gt; strongly suggest that it should resort to the
&quot;send all your </font><br>
<font size=2>&gt; updates through me&quot; solution described for
Microsoft updates </font><br>
<font size=2>&gt; in earlier messages).</font> <br><br>
<font size=2>Why limit the arrangement such that the contracted service
can manage everything?&nbsp; It doesn't seem like much of a stretch to
use constraints similar to those we've discussed for application TAs,
i.e., name constraints or usage constraints.<br>
</font><br>
<font size=2>&nbsp;</font> <br>
<font size=2>&lt;snip&gt;</font> <br>
<font size=2>&gt; One more item.&nbsp; Russ wrote:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; &gt; I see no reason for there to me more than one
all-powerful </font><br>
<font size=2>&gt; TA as long </font><br>
<font size=2>&gt; &gt; as the all-powerful TA can be used to make updates
to the </font><br>
<font size=2>&gt; all-powerful </font><br>
<font size=2>&gt; &gt; TA, say when two enterprises merge.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; The reason may be dealing with private key compromise
in a </font><br>
<font size=2>&gt; tractable fashion - if an all-powerful TA needs to be
revoked </font><br>
<font size=2>&gt; (e.g., via a CRL), it would be more than convenient to
have </font><br>
<font size=2>&gt; another one to use.&nbsp; Two should be enough.</font>
<br><br>
<font size=2>This suggests we need to be able to represent: a pair all
powerful TSAs, if for no other reason than recovery from compromise or
loss; one or more(?) less-powerful TSAs; and a set of
ATAs.</font></blockquote></body>
</html>

[Carl Wallace]

Here's a variation that references digital signatures:

A trust anchor represents an authoritative source of one or more types of
information. Trust anchors are comprised of a public key and associated
data. The public key is used to verify digital signatures and the
associated data is used to constrain the types of information for which the
trust anchor is authoritative. Relying parties use trust anchors to
determine if digitally signed information objects are valid by verifying
digital signatures using the trust anchor's public key and by enforcing the
constraints expressed in the associated data.

> -----Original Message-----
> From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of
> Diego R. Lopez
> Sent: Monday, August 20, 2007 2:40 PM
> To: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
>
> On 20 Aug 2007, at 19:49, Stephen Kent wrote:
> > At 12:09 PM -0400 8/18/07, Turner, Sean P. wrote:
> >> ...
> >>
> >> The glossary's definition had more in the 1st sentence which
> >> basically said what the suggested second sentence said - so I get
> >> your point about mushy fruit. I agree that the authority
> is a central
> >> concept to TAM and that's what I was alluding to with my context
> >> comment. I think it ought to be in the definition. How about:
> >>
> >> A trust anchor is a public key and associated data that
> represents an
> >> authoritative source of some type of information.
> Associated data is
> >> used to define the scope of the use of the trust anchor
> including the
> >> authorized type of information.
> > I still find this too mushy :-). I'd like to see some mention of
> > digital signatures in the definition. That seems to be an essential
> > feature of TAs, irrespective of the use of certs (of any type) vs.
> > raw keys.
>
> Ditto. In despite of the format used (certificates or
> whatever), a TA deals with the verification of digital signatures.
>
>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
>
> Red.es - RedIRIS
> The Spanish NREN
>
> e-mail: diego.lopez-***@public.gmane.org
> jid: drlopez-bva+***@public.gmane.org
> Tel: [phone]
> Mobile: [phone]
> -----------------------------------------
>
>

[Stephen Kent]

At 4:52 PM -0400 8/20/07, Carl Wallace wrote:
>Here's a variation that references digital signatures:
>
>A trust anchor represents an authoritative source of one or more
>types of information. Trust anchors are comprised of a public key
>and associated data. The public key is used to verify digital
>signatures and the associated data is used to constrain the types of
>information for which the trust anchor is authoritative. Relying
>parties use trust anchors to determine if digitally signed
>information objects are valid by verifying digital signatures using
>the trust anchor's public key and by enforcing the constraints
>expressed in the associated data.
>


Carl,

That's much better, but I don't see why the first sentence has to be
so broad. How about: "A trust anchor represents an authoritative
entity represented by a public key and associated data."

Steve

[Frank Siebenlist]

Why do we need the emphasis on "public key" and "digitally signing" with
respect to trust anchors?

I can think of trust anchors that could be identified through a kerberos
principal name or a DN, and online trust anchors that can be queried for
info over an authenticated tls connection...


-Frank.


Stephen Kent wrote:
>
> At 4:52 PM -0400 8/20/07, Carl Wallace wrote:
>> Here's a variation that references digital signatures:
>>
>> A trust anchor represents an authoritative source of one or more types
>> of information. Trust anchors are comprised of a public key and
>> associated data. The public key is used to verify digital signatures
>> and the associated data is used to constrain the types of information
>> for which the trust anchor is authoritative. Relying parties use
>> trust anchors to determine if digitally signed information objects are
>> valid by verifying digital signatures using the trust anchor's public
>> key and by enforcing the constraints expressed in the associated data.
>
>
> Carl,
>
> That's much better, but I don't see why the first sentence has to be so
> broad. How about: "A trust anchor represents an authoritative entity
> represented by a public key and associated data."
>
> Steve
>

--
Frank Siebenlist franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Stephen Kent]

At 5:44 PM -0700 8/20/07, Frank Siebenlist wrote:
>Why do we need the emphasis on "public key" and "digitally signing" with
>respect to trust anchors?
>
>I can think of trust anchors that could be identified through a kerberos
>principal name or a DN, and online trust anchors that can be queried for
>info over an authenticated tls connection...
>
>-Frank.

Frank,

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 :-).

Steve

[Paul Hoffman]

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]

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-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Santosh Chokhani]

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-064uVg1PTMq+***@public.gmane.org
[mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
Siebenlist
Sent: Tuesday, August 21, 2007 1:40 AM
To: Paul Hoffman
Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Frank Siebenlist]

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-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
> Siebenlist
> Sent: Tuesday, August 21, 2007 1:40 AM
> To: Paul Hoffman
> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Santosh Chokhani]

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-zhzY/AYb9nBYTrM/***@public.gmane.org]
Sent: Tuesday, August 21, 2007 11:12 AM
To: Santosh Chokhani
Cc: ietf-trust-anchor-***@public.gmane.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: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
> Siebenlist
> Sent: Tuesday, August 21, 2007 1:40 AM
> To: Paul Hoffman
> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Frank Siebenlist]

Two scenarios:

* Kerberos is already deployed, which implies that any all principals
can communicate securely with each other. Through a Kerberized
Certificate Authority, a user can obtain short-lived certs. It could
also obtain all the trust root info from another kerberized service,
including all the root CAs that can be trusted outside of that domain
(not implemented yet...). No need for any pre-configured public key on
the clients, and no need for dsig.
(kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/)

* Use TLS with a pre-shared secret and key-exchange authentication
protocol, which doesn't require any server cert or pre-configured public
key for the mutually-authenticated trust establishment. Use this primary
authN mechanism to front-end an online-CA and trust-root provisioning
service, and again no need for any pre-configured public key, and no
need for dsig.
http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent)
Myproxy is a good example of a credential issuing service that can work
as an online-CA, has a pluggable primary authentication (no pre-shared
secret support yet...), and transparent provisioning capabilities.
(http://grid.ncsa.uiuc.edu/myproxy/)
Another example is caBIG's Grid Trust Service (GTS), which is such a
trust-root provisioning service that relies on a pre-configured
public-key/x509cert (but we plan/dream to enhance it in the future to
support other bootstrapping mechanisms)
(http://www.cagrid.org/mwiki/index.php?title=GTS:Main)

In all cases, we would like to standardize the trust root provisioning
protocol without having to mandate any boots-trapping public key. Just
having the message exchange protocol with standardized formats for the
trust-anchor info including meta-data for the anchor's issuing
constraints would be great. The security mechanism to use relies on the
pre-configured shared-secrets/OTP/Kerberos/password/public-key, and
should not be mandated IMHO.

Hope that explains.

-Frank.




Santosh Chokhani wrote:
> 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-zhzY/AYb9nBYTrM/***@public.gmane.org]
> Sent: Tuesday, August 21, 2007 11:12 AM
> To: Santosh Chokhani
> Cc: ietf-trust-anchor-***@public.gmane.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: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
>> Siebenlist
>> Sent: Tuesday, August 21, 2007 1:40 AM
>> To: Paul Hoffman
>> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[B***@public.gmane.org]

> In all cases, we would like to standardize the trust root provisioning
> protocol without having to mandate any boots-trapping public key. Just
> having the message exchange protocol with standardized formats for the
> trust-anchor info including meta-data for the anchor's issuing
> constraints would be great. The security mechanism to use relies on
the
> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and
> should not be mandated IMHO.

If this is primarily about bootstrapping, it concerns only the
TSAs (Trust Store Anchors), and it looks like Frank would like
it to be possible for them to be something other than public
keys, while the actual application trust anchors provisioned
into the trust stores would be public keys.

In all the scenarios
Frank outlines, the trust anchor management has to be online -
the trust anchor operations have to come down the secure channel
that was authenticated by non-PKI means (i.e., store and forward
via something like a USB key is a non-starter - digital signatures
are needed for that sort of scenario). With this restriction, I
could envision a TSA being a Kerberos realm and principal.

OTOH, I'm not enthusiastic about pre-shared secret (e.g., for
TLS) and pluggable authentication because the notion of identity
of the TSA is unclear. I think requiring the TAA to have a
public/private key pair is reasonable, and then the bootstrapping
mechanism for these cases would be:
1) Set up a secure channel authenticated by some means
(sneaker-net if necessary).
2) Get the TAA's public key and install that as the TSA.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david-***@public.gmane.org Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of
> Frank Siebenlist
> Sent: Tuesday, August 21, 2007 6:25 PM
> To: Santosh Chokhani
> Cc: ietf-trust-anchor-***@public.gmane.org
> Subject: Re: Draft Charter
>
>
> Two scenarios:
>
> * Kerberos is already deployed, which implies that any all principals
> can communicate securely with each other. Through a Kerberized
> Certificate Authority, a user can obtain short-lived certs. It could
> also obtain all the trust root info from another kerberized service,
> including all the root CAs that can be trusted outside of that domain
> (not implemented yet...). No need for any pre-configured public key on
> the clients, and no need for dsig.
> (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/)
>
> * Use TLS with a pre-shared secret and key-exchange authentication
> protocol, which doesn't require any server cert or pre-configured
public
> key for the mutually-authenticated trust establishment. Use this
primary
> authN mechanism to front-end an online-CA and trust-root provisioning
> service, and again no need for any pre-configured public key, and no
> need for dsig.
> http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent)
> Myproxy is a good example of a credential issuing service that can
work
> as an online-CA, has a pluggable primary authentication (no pre-shared
> secret support yet...), and transparent provisioning capabilities.
> (http://grid.ncsa.uiuc.edu/myproxy/)
> Another example is caBIG's Grid Trust Service (GTS), which is such a
> trust-root provisioning service that relies on a pre-configured
> public-key/x509cert (but we plan/dream to enhance it in the future to
> support other bootstrapping mechanisms)
> (http://www.cagrid.org/mwiki/index.php?title=GTS:Main)
>
> In all cases, we would like to standardize the trust root provisioning
> protocol without having to mandate any boots-trapping public key. Just
> having the message exchange protocol with standardized formats for the
> trust-anchor info including meta-data for the anchor's issuing
> constraints would be great. The security mechanism to use relies on
the
> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and
> should not be mandated IMHO.
>
> Hope that explains.
>
> -Frank.
>
>
>
>
> Santosh Chokhani wrote:
> > 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-zhzY/AYb9nBYTrM/***@public.gmane.org]
> > Sent: Tuesday, August 21, 2007 11:12 AM
> > To: Santosh Chokhani
> > Cc: ietf-trust-anchor-***@public.gmane.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: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
> >> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
> >> Siebenlist
> >> Sent: Tuesday, August 21, 2007 1:40 AM
> >> To: Paul Hoffman
> >> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
> The Globus Alliance - Argonne National Laboratory
>
>
>

[Frank Siebenlist]

Your "translation" sounds good ;-)

I just don't understand your concern about tls with pre-shared secret -
kerberos' security would be enhanced when it would deploy that for it's
password-based authN+keyexchange - it seems to me like a better authN
protocol to use for any password/OTP-based mechanism...


Your solution:

> 1) Set up a secure channel authenticated by some means
> (sneaker-net if necessary).
> 2) Get the TAA's public key and install that as the TSA.

is less efficient and less secure (one more unnecessary chain) than
simply using the already established security context to provision the
client...

-Frank.

PS. Note that any of these online-PKIs which is derived/bootstrapped
from another primary authN mechanism is less "trusted/secure" than that
primary authN mechanism - it's up to the organization's policy whether
that is "secure enough" for their deployment (...and in most cases it is).



Black_David-***@public.gmane.org wrote:
>> In all cases, we would like to standardize the trust root provisioning
>> protocol without having to mandate any boots-trapping public key. Just
>> having the message exchange protocol with standardized formats for the
>> trust-anchor info including meta-data for the anchor's issuing
>> constraints would be great. The security mechanism to use relies on
> the
>> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and
>> should not be mandated IMHO.
>
> If this is primarily about bootstrapping, it concerns only the
> TSAs (Trust Store Anchors), and it looks like Frank would like
> it to be possible for them to be something other than public
> keys, while the actual application trust anchors provisioned
> into the trust stores would be public keys.
>
> In all the scenarios
> Frank outlines, the trust anchor management has to be online -
> the trust anchor operations have to come down the secure channel
> that was authenticated by non-PKI means (i.e., store and forward
> via something like a USB key is a non-starter - digital signatures
> are needed for that sort of scenario). With this restriction, I
> could envision a TSA being a Kerberos realm and principal.
>
> OTOH, I'm not enthusiastic about pre-shared secret (e.g., for
> TLS) and pluggable authentication because the notion of identity
> of the TSA is unclear. I think requiring the TAA to have a
> public/private key pair is reasonable, and then the bootstrapping
> mechanism for these cases would be:
> 1) Set up a secure channel authenticated by some means
> (sneaker-net if necessary).
> 2) Get the TAA's public key and install that as the TSA.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> [phone] FAX: [phone]
> black_david-***@public.gmane.org Mobile: [phone]
> ----------------------------------------------------
>
>> -----Original Message-----
>> From: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of
>> Frank Siebenlist
>> Sent: Tuesday, August 21, 2007 6:25 PM
>> To: Santosh Chokhani
>> Cc: ietf-trust-anchor-***@public.gmane.org
>> Subject: Re: Draft Charter
>>
>>
>> Two scenarios:
>>
>> * Kerberos is already deployed, which implies that any all principals
>> can communicate securely with each other. Through a Kerberized
>> Certificate Authority, a user can obtain short-lived certs. It could
>> also obtain all the trust root info from another kerberized service,
>> including all the root CAs that can be trusted outside of that domain
>> (not implemented yet...). No need for any pre-configured public key on
>> the clients, and no need for dsig.
>> (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/)
>>
>> * Use TLS with a pre-shared secret and key-exchange authentication
>> protocol, which doesn't require any server cert or pre-configured
> public
>> key for the mutually-authenticated trust establishment. Use this
> primary
>> authN mechanism to front-end an online-CA and trust-root provisioning
>> service, and again no need for any pre-configured public key, and no
>> need for dsig.
>> http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent)
>> Myproxy is a good example of a credential issuing service that can
> work
>> as an online-CA, has a pluggable primary authentication (no pre-shared
>> secret support yet...), and transparent provisioning capabilities.
>> (http://grid.ncsa.uiuc.edu/myproxy/)
>> Another example is caBIG's Grid Trust Service (GTS), which is such a
>> trust-root provisioning service that relies on a pre-configured
>> public-key/x509cert (but we plan/dream to enhance it in the future to
>> support other bootstrapping mechanisms)
>> (http://www.cagrid.org/mwiki/index.php?title=GTS:Main)
>>
>> In all cases, we would like to standardize the trust root provisioning
>> protocol without having to mandate any boots-trapping public key. Just
>> having the message exchange protocol with standardized formats for the
>> trust-anchor info including meta-data for the anchor's issuing
>> constraints would be great. The security mechanism to use relies on
> the
>> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and
>> should not be mandated IMHO.
>>
>> Hope that explains.
>>
>> -Frank.
>>
>>
>>
>>
>> Santosh Chokhani wrote:
>>> 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-zhzY/AYb9nBYTrM/***@public.gmane.org]
>>> Sent: Tuesday, August 21, 2007 11:12 AM
>>> To: Santosh Chokhani
>>> Cc: ietf-trust-anchor-***@public.gmane.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: owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org
>>>> [mailto:owner-ietf-trust-anchor-064uVg1PTMq+***@public.gmane.org] On Behalf Of Frank
>>>> Siebenlist
>>>> Sent: Tuesday, August 21, 2007 1:40 AM
>>>> To: Paul Hoffman
>>>> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor-***@public.gmane.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 franks-zhzY/AYb9nBYTrM/***@public.gmane.org
>> The Globus Alliance - Argonne National Laboratory
>>
>>
>>
>

--
Frank Siebenlist franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[B***@public.gmane.org]

Frank,

> Your "translation" sounds good ;-)
>
> I just don't understand your concern about tls with pre-shared secret
-
> kerberos' security would be enhanced when it would deploy that for
it's
> password-based authN+keyexchange - it seems to me like a better authN
> protocol to use for any password/OTP-based mechanism...

There may be some confusion about who/what is being authenticated/
authorized. The point of the Trust Store Anchor (TSA) is to authorize
the Trust Anchor Administrator (TAA) to manage the local store of trust
anchors. Note that the local client/user does not need to be
authenticated as part of authorizing this management - the local
authentication is only needed to bootstrap the trust store authorization
mechanism. Once the authorization is in place, only the TAA's identity
has to be verified in order to determine whether to permit or deny trust
anchor management operations.

> Your solution:
>
> > 1) Set up a secure channel authenticated by some means
> > (sneaker-net if necessary).
> > 2) Get the TAA's public key and install that as the TSA.
>
> is less efficient and less secure (one more unnecessary chain) than
> simply using the already established security context to provision the
> client...

I disagree with both "less efficient" and "less secure". If the client
(holder of the password, OTP, etc.) has to be authenticated as part of
every trust anchor management action performed by the TAA, I would
agree with you. That's not the situation here - the installation
of the TAA's public key as a TSA is an enrollment-like scenario - it
only needs to be done once, after which it is not necessary to
re-authenticate the client.

There are two important consequences:
(1) Once the TAA's public key is installed, a secure channel to the TAA
is no longer needed to perform trust anchor management - the TAA
can sign the ops and not have to worry about how they're
delivered.
This may be an efficiency gain (one digital signature vs. all
the
work in setting up and using a secure channel). It may also be
a
security gain, as the TAA can have its signing key offline with
respect to the trust anchor management operations - in contrast,
whatever is used to authenticate a secure channel has to be
online
with respect to setup of that channel.
(2) Loss of the client's authentication credentials does not expose the
trust store as long as no TSA change has been made using the
compromised credentials. In particular, if the client has no
ability to change TSAs (makes sense in an enterprise scenario),
then the trust store depends only on the TAA's private key,
which
was not lost when the client lost her authentication
credentials,
and that's probably a security gain.
For Kerberos, I see no problem in using a principal, because I expect
the client to always have that infrastructure set up for other reasons,
and because Kerberos isolates the password (vs. having to use it every
time for everything).

> PS. Note that any of these online-PKIs which is derived/bootstrapped
> from another primary authN mechanism is less "trusted/secure" than
that
> primary authN mechanism - it's up to the organization's policy
whether
> that is "secure enough" for their deployment (...and in most cases it
is).

If I take that argument to its logical conclusion, there's no point in
using TSAs at all, as the local trust store is at the client's mercy,
but there are scenarios in which that is definitely *not* the case.
The definition of trust anchor management operations (unsigned) might
be useful in the absence of TSAs, but also see the above discussion of
one-time installation of a public key as a TSA vs. relying on client
authentication every time.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david-***@public.gmane.org Mobile: [phone]
----------------------------------------------------

[Stephen Kent]

At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote:
>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.

I believe your experience is an accurate characterization for the
grid computing community, but not most other communities who make use
of PKI.

Steve

[Frank Siebenlist]

Stephen Kent wrote:
> At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote:
>> 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.
>
> I believe your experience is an accurate characterization for the grid
> computing community, but not most other communities who make use of PKI.

Well...I wouldn't dismiss our experience too fast.

The grid community has a lot of experience with the old fashion, heavy
weight PKI infrastructure with "real" CAs issuing long-lived certs to
users - probably more than most other commercial applications as the
last time I checked real PKI never lived up to its promise (who are all
those other communities that you are referring to ?).

The reasons why there is a push towards online CAs is because the heavy
administrative burden associated with running a double authN
infrastructure, and because of security concerns.

Our experience is that most organizations already have (at least...) one
identity management systems in place, which is "never" based on PKI and
they will not and cannot abandon that for a PKI. Being able to leverage
an existing identity management system is very compelling. Lastly,
issuing short-lived certs also removes the revocation issues; dealing
with those was never a strong point of PKI (it actually leaves the
revocation issue with the other Id management system).

The security issue with long lived certs has to do with the fact that we
cannot trust the desktops anymore because of all the compromises through
worms, viruses, bots, etc. Storing private keys on desktops protected by
pass-phrases is a loosing proposition and compromised keys are expensive
from a revocation, recovery, and management point of view. So unless you
can rely on smartcards for your private key store and signing, your
deployment is saver and recovery is easier when you rely on
passwords/OTP with onlineCAs+sortlived-certs.

I wouldn't be surprised if the grid communities' pki-experience could be
applied to many other communities in the (near) future, which would make
it too bad if this effort wouldn't accommodate a more broader view on "PKI".

-Frank.


--
Frank Siebenlist franks-zhzY/AYb9nBYTrM/***@public.gmane.org
The Globus Alliance - Argonne National Laboratory

[Stephen Kent]

At 8:10 PM -0700 8/21/07, Frank Siebenlist wrote:
>Stephen Kent wrote:
>> At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote:
>>> 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.
>>
>> I believe your experience is an accurate characterization for the grid
>> computing community, but not most other communities who make use of PKI.
>
>Well...I wouldn't dismiss our experience too fast.
>
>The grid community has a lot of experience with the old fashion, heavy
>weight PKI infrastructure with "real" CAs issuing long-lived certs to
>users - probably more than most other commercial applications as the
>last time I checked real PKI never lived up to its promise (who are all
>those other communities that you are referring to ?).

The U.S. DoD, in issuing CACs as well as certs for use with software
is an obvious example of a large scale CA issuing long-lived certs. A
number of large enterprises have issued certs to employees. Tens of
millions of smart card users in Europe and Asia are holders of long
lived certs too, although most don't know it.


>The reasons why there is a push towards online CAs is because the heavy
>administrative burden associated with running a double authN
>infrastructure, and because of security concerns.

I'm not sure I know what you mean by "running a double authN
infrastructure." Is this an allusion to folks who run Kerberos or
RADIUS server, and who then decide to add a PKI because these don't
support some apps that make use of PKI?

>Our experience is that most organizations already have (at least...) one
>identity management systems in place, which is "never" based on PKI and
>they will not and cannot abandon that for a PKI.

First, the term "identity management system" is a neologism created
by marketing folks :-). But yes, there is always resistance to
change, and not everyone will benefit enough from a PKI to warrant
the change.

> Being able to leverage
>an existing identity management system is very compelling.

Leveragng can take the form of using an extant system to issue certs,
and then moving on. But, if "leveraging" means never changing out the
old system, then of course there is a price to pay.

>Lastly,
>issuing short-lived certs also removes the revocation issues; dealing
>with those was never a strong point of PKI (it actually leaves the
>revocation issue with the other Id management system).

yes, short-lived certs avoid revocation worries, as well as
precluding use of certs for apps like secure e-mail.

I disagree with your assertion that dealing with revocation is an
inherent weak point of PKI architecture. The CRL model is reasonable
if people think through validity intervals, and if they don't have
sever bandwidth constraints for delivering CRLs. Yes, if one makes
bad choices, then CRLs can grow to be enormous (the CAC is a poster
boy for a bad design in this regard). OCSP is a reasonable
alternative, although too often folks think it provide fresher info,
which is often not the case. In general I believe there has been too
much emphasis on the speed with which revocation data must be made
available to RPs. In reality, revocation is usually a process that
requires human intervention and that will be the gating aspect of the
process.

>The security issue with long lived certs has to do with the fact that we
>cannot trust the desktops anymore because of all the compromises through
>worms, viruses, bots, etc. Storing private keys on desktops protected by
>pass-phrases is a loosing proposition and compromised keys are expensive
>from a revocation, recovery, and management point of view. So unless you
>can rely on smartcards for your private key store and signing, your
>deployment is saver and recovery is easier when you rely on
>passwords/OTP with onlineCAs+sortlived-certs.

First, if one is serious about user authentication, some form of
hardware assist is needed, period. This could be a TPM, a smart card,
a USB token, or even a SecurID fob. When one constrains the solution
space to make use only of software, then you're already in trouble.

Your argument about the advantages of short-lived certs (and private
keys) vs. long-lived certs has merit, but lacks important details.
For example, if issuance of a short-lived cert relies on purely
password-based authentication, you're still in trouble. if you use an
OTP token, then you are better off because of the use of that
hardware. However, persistent, malicious software will be able to
grab the resulting private key every time it is created, and send it
to a bad guy. Worese yet, if you rely on PRNG software on the
desktop, a smart adversary might replace it with something that makes
it easy to predict the private keys you will generate. So, the bottom
line security differences between long and short-lived certs and keys
is less dramatic than you suggest.

Steve

[Leif Johansson]

>
>> Our experience is that most organizations already have (at least...) one
>> identity management systems in place, which is "never" based on PKI and
>> they will not and cannot abandon that for a PKI.
>
> First, the term "identity management system" is a neologism created by
> marketing folks :-). But yes, there is always resistance to change,
> and not everyone will benefit enough from a PKI to warrant the change.
Stephen,

With all due respect...

Perhaps with your experience Franks argument don't make sense but
I should not be so quick to dismiss him based on wording alone. The
situations he describes are everyday reality for many of us in the higher-
ed community and not just because we are all lazy bums who haven't
figured out that we need to convert our processes from issuing
kerberos identities to issuing smart-cards with certs.

I don't believe your characterization of identity management as a
marketing ploy contributes much to figuring out the merit of the
use-cases Frank has presented.

Cheers Leif

[Leif Johansson]

Stephen Kent wrote:
>
> At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote:
>> 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.
>
> I believe your experience is an accurate characterization for the grid
> computing community, but not most other communities who make use of PKI.
>
> Steve
>
Steve,

This use-case is not at all limited to the grid-community. In fact
the kx509 tool Frank mentioned wasn't originally a "grid thing".

Cheers Leif

[Stephen Kent]

At 10:39 PM -0700 8/20/07, Frank Siebenlist wrote:
>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.

if we make the definition very general, we can include DHCP, since it
clearly is a source of authority for data, e.g., first hop router,
DNS server, ...

Howeverm I don't think that is what most of the folks on this mailing
list had in mind when they signed up for a discussion of trust anchor
management.

Steve

[Carl Wallace]

> Carl,
>
> That's much better, but I don't see why the first sentence
> has to be so broad. How about: "A trust anchor represents an
> authoritative entity represented by a public key and associated data."
>
> Steve
>

That works for me.

Carl

[Carl Wallace]

> In all cases, we would like to standardize the trust root
> provisioning protocol without having to mandate any
> boots-trapping public key. Just having the message exchange
> protocol with standardized formats for the trust-anchor info
> including meta-data for the anchor's issuing constraints
> would be great. The security mechanism to use relies on the
> pre-configured
> shared-secrets/OTP/Kerberos/password/public-key, and should
> not be mandated IMHO.
>
> Hope that explains.
>
> -Frank.
>

It seems like the issue is more with a comment in section 4 of the problem
statement regarding the placement of at least one public key in a device
during initialization than with the TA definition that preceded this
discussion. I propose we adopt a public key/signature-focused TA
definition, soften the language in the problem statement regarding the
bootstrap public key and address these issues when we define the security
mechanisms for TA mgmt messages. There may be some additional tweaks to the
problem statement resulting from this discussion as well.