Subject: TAM as a new WG item?

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Dec 2007 12:46:32 -0500

At the PKIX meeting this week we hosted a presentation on trust 
anchor management (TAM).  The presentation described a rich trust 
anchor (TA) model and a management protocol expressed in an ASN.1 
syntax.  The model accommodates three types of TAs, and an 
authorization scheme for managing TAs and other signed objects that 
might be associated with a crypto module (a hardware or software 
implementation of crypto capabilities managed by one of more 
administrative entities). The protocol accommodates both online and 
offline (staged delivery) management of a module, i.e., it is 
transport independent and does not require realtime connectivity.

TAM is obviously of interest to PKIX members, as we make use of TAs 
for cert path discovery and validation. However, TAs can be used in 
more general contexts as well, e.g., for directly validating 
signatures on CMS objects. Moreover, the issue of TA management is 
potentially broader than just the X.509 context, i.e., one could 
imagine developing a TA model and protocol that deals with other cert 
types (e.g., PGP) and with public (signature) keys independent of 
certs.  Despite the important role that TAs play in PKIX-based 
implementations, the WG has never adopted a work item to develop a 
model for the management of TAs, nor specified a protocol for remote 
TA management.

At the 69th IETF meeting there was a BoF to explore creating a new WG 
to pursue development of a TA model and associated remote management 
protocol, and a mailing list was established to develop a charter, 
etc.  Tim Polk has decided that there is not critical mass to create 
a separate WG for this purpose. However, Tim is willing to have PKIX 
take on the effort as a new work item. If we do adopt this as a work 
item, we will focus on TAs primarily in the X.509 context,consistent 
with the PKIX charter.

At the WG meeting in Vancouver this week I asked the room if there 
were any objections to PKIX adopting this a work item, given that we 
have permission from Tim to do so. Two folks voiced objections; both 
agreed that pursuing TAM was important, but preferred creation of a 
new WG for the task. However, that option is not on the table at this 
time and thus is not a subject of the straw poll noted below.

So I am calling for a straw poll in PKIX to gauge interest in pursing 
this topic. The poll begins today and will end in two weeks, on 
12/19.  Please examine the presentation slides to get a sense of what 
work has been done already: 
http://www3.ietf.org/proceedings/07dec/slides/pkix-2.pdf

Thanks,

Steve

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 5 Dec 2007 10:41:47 -0800

I am in favor of pursuing this topic.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Stephen Kent
>Sent: Wednesday, December 05, 2007 9:47 AM
>To: [email-masked]
>Subject: TAM as a new WG item?
>
>
>At the PKIX meeting this week we hosted a presentation on 
>trust anchor management (TAM).  The presentation described a 
>rich trust anchor (TA) model and a management protocol 
>expressed in an ASN.1 syntax.  The model accommodates three 
>types of TAs, and an authorization scheme for managing TAs and 
>other signed objects that might be associated with a crypto 
>module (a hardware or software implementation of crypto 
>capabilities managed by one of more administrative entities). 
>The protocol accommodates both online and offline (staged 
>delivery) management of a module, i.e., it is transport 
>independent and does not require realtime connectivity.
>
>TAM is obviously of interest to PKIX members, as we make use 
>of TAs for cert path discovery and validation. However, TAs 
>can be used in more general contexts as well, e.g., for 
>directly validating signatures on CMS objects. Moreover, the 
>issue of TA management is potentially broader than just the 
>X.509 context, i.e., one could imagine developing a TA model 
>and protocol that deals with other cert types (e.g., PGP) and 
>with public (signature) keys independent of certs.  Despite 
>the important role that TAs play in PKIX-based 
>implementations, the WG has never adopted a work item to 
>develop a model for the management of TAs, nor specified a 
>protocol for remote TA management.
>
>At the 69th IETF meeting there was a BoF to explore creating a 
>new WG to pursue development of a TA model and associated 
>remote management protocol, and a mailing list was established 
>to develop a charter, etc.  Tim Polk has decided that there is 
>not critical mass to create a separate WG for this purpose. 
>However, Tim is willing to have PKIX take on the effort as a 
>new work item. If we do adopt this as a work item, we will 
>focus on TAs primarily in the X.509 context,consistent with 
>the PKIX charter.
>
>At the WG meeting in Vancouver this week I asked the room if 
>there were any objections to PKIX adopting this a work item, 
>given that we have permission from Tim to do so. Two folks 
>voiced objections; both agreed that pursuing TAM was 
>important, but preferred creation of a new WG for the task. 
>However, that option is not on the table at this time and thus 
>is not a subject of the straw poll noted below.
>
>So I am calling for a straw poll in PKIX to gauge interest in 
>pursing this topic. The poll begins today and will end in two 
>weeks, on 12/19.  Please examine the presentation slides to 
>get a sense of what work has been done already:

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Dec 2007 19:18:05 +0000

Iff a new WG isn't possible, then I agree that pursuing
TAM in PKIX is best. (A consequence being that PKIX will
quite possibly not end until well into its mid-teens:-()

If doing TAM in PKIX ends up being the consensus, I think
a secondary issue would be whether or not CCC should be in
PKIX or SMIME or is in fact just too complicated. (TAMP
as it stands is also maybe a bit over complicated for
simpler use cases.)

Basically, that's a +1 with non-trivial caveats, maybe
about a +0.25:-)

Stephen.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 5 Dec 2007 11:58:23 -0800

I support PKIX adopting TAM work item.
\
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Wednesday, December 05, 2007 12:47 PM
To: [email-masked]
Subject: TAM as a new WG item?

Thanks,

Steve

---

From: "Peter Hesse" <[email-masked]>
Date: Wed, 5 Dec 2007 16:30:17 -0500

I am in favor of supporting TAM as a PKIX work item.

----------------------------------------------------------------
  Peter Hesse                      [email-masked]
  Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.
        Visit our InfoSecurity blog: securitymusings.com

"The generation of random numbers is too important to be left
 to chance." --Robert R. Coveyou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Wednesday, December 05, 2007 12:47 PM
To: [email-masked]
Subject: TAM as a new WG item?

Thanks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 05 Dec 2007 16:41:01 -0500

I believe that PKIX should adopt this work and generate 
standards-track document(s) in this area.

Russ

At 12:46 PM 12/5/2007, Stephen Kent wrote:

>imagine developing a TA model and protocol that deals with other 
>cert types (e.g., PGP) and with public (signature) keys independent 
>of certs.  Despite the important role that TAs play in PKIX-based 
>At the 69th IETF meeting there was a BoF to explore creating a new 
>WG to pursue development of a TA model and associated remote 
>management protocol, and a mailing list was established to develop a 
>charter, etc.  Tim Polk has decided that there is not critical mass 
>to create a separate WG for this purpose. However, Tim is willing to 
>have PKIX take on the effort as a new work item. If we do adopt this 
>as a work item, we will focus on TAs primarily in the X.509 
>context,consistent with the PKIX charter.
>
>new WG for the task. However, that option is not on the table at 
>this time and thus is not a subject of the straw poll noted below.
>
>pursing this topic. The poll begins today and will end in two weeks, 
>on 12/19.  Please examine the presentation slides to get a sense of 
>what work has been done already:

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 05 Dec 2007 14:21:07 -0800

> as it stands is also maybe a bit over complicated for

Not a problem. The next step then will be the development of STAMP (Simple 
Trust Anchor Management Protocol) :-)

Robert

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 05 Dec 2007 14:38:14 -0800

Hi all,

I am in favor of adopting TAM in PKIX. Especially after having attended
the presentation yesterday. Indeed, I think that a TAM is something that,
in some controlled environment, is really interesting and needed, e.g.
Computing Grid PKIs or other communities (HEBCA/etc...).

I do also think that it **SHOULD** be pursued in PKIX. I think that we
need TAM to support PKIs first and eventually other scenarios/usages
later.

Keeping it simple and not overcomplicated it is, to me, an important point.
I fear that TAM would become somewhat too general and too complicated if
a specific WG will cover its definition.

IMHO.

Side Note:

Will this influence the lifespan of PKIX WG ? Well, I do think that this
WG (PKIX) has still a *lot* of things to address for PKIs to be usable and
allow them to be deployed in the real world. And I am quite sure that when
(if ever) PKIX will be shut down, the proposal for a new one will appear in the
next IETF (e.g. LPKIX - Large PKIX ? hehhehe ). Sorry Tim, but I do
really believe that, so far, shutting down PKIX would be an error also
because other WGs count on the presence of this WG for PKI integration
into their work. (sorry for the OT.. :D)

Later,
Max

Stephen Kent wrote:
> 
> At the PKIX meeting this week we hosted a presentation on trust anchor 
[...]
> been done already: http://www3.ietf.org/proceedings/07dec/slides/pkix-2.pdf

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

---

From: Sanjaya <[email-masked]>
Date: Thu, 06 Dec 2007 09:40:58 +1000

I support this idea. Thanks.

Sanjaya

Stephen Kent wrote:

> this topic. The poll begins today and will end in two weeks, on 12/19.  
> Please examine the presentation slides to get a sense of what work has

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Dec 2007 10:06:50 +0200

I am also in favor of adopting TAM as a working group item, although  
like Stephen, I would also have liked it to be in its own WG.

I am less than enthusiastic about the current proposal, as I don't  
think it addresses everything we need on the one hand, and is too  
complicated on the other.

But first priority is to find a venue for this work, and if it can't  
be TAM, it should be PKIX.

After that we can argue the relative merits of TAMP and STAMP :-)

Yoav

On Dec 6, 2007, at 12:21 AM, Robert Kisteleki wrote:

> Not a problem. The next step then will be the development of STAMP  
> (Simple Trust Anchor Management Protocol) :-)
>
> Robert
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 8 Dec 2007 07:57:24 +0100

The following is dedicated to the folks who presumably will make TAM
a PKIX WG item.

Today "remote control" of devices like laptop computers and mobile phones
is already a fact.  For the latter there is a scheme known as OMA-DM which
is used not only for distributing cryptographic keys, but software updates and
"registry" settings.   I don't really see that trust anchors differ from any other
piece of information that an organization wants to securely maintain in their fleet
of client computers.

"Unmanaged" devices like consumer computers seems to be a white spot but
IMO automatic software updates + various services that the browser vendors
supply, essentially do what is technically feasible in assuring that the user is
connecting to a credible site (the #1 problem on the Internet).

thanks
Anders Rundgren

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 08 Dec 2007 00:08:36 -0800

Hi Anders,

the question is: how does this OMA-DM stand in respect of IETF ? Has it been
submitted as I-D or as any other form of contribution ?

Moreover as I understand this is based on XML which could be not the best
choice for small devices (no, not mobile phones.. smaller devices like
sensors... )

Anyhow, I would like to see a proposal for an rfc (if the people that developed
the OMA-DM are interesting in having it standardized within the IETF)
before saying that this is a "deal done"...

Maybe it could be a *starting point* together with the current proposal..
(do you know of any patents/IP pending ?)

BTW, I do really disagree with you when you say that trust anchors don't
differ from other piece of information... they are far more important than
a single configuration/etc.. and their distribution can impact across
different organizations and VOs. An important aspect that we should address
is the level of involvement of the user: in some environment it is acceptable
that the organization controls the TAs, in some others the user should always
be in control over its own computer (!!!!).

Later,
Max

---

From: Russ Housley <[email-masked]>
Date: Sat, 08 Dec 2007 10:03:33 -0500

There was a lot of support for adding this work item to PKIX, but the 
proposed text for the rechartering of the WG has not been sent to the 
IESG for approval yet.

Russ

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 9 Dec 2007 09:11:05 +0100

Max,
Since I have no interest in TAM, feel free to ignore my
long-winding comment :-)

Personally I find it odd that the PKI community (not limited to
PKIX) considers TAM more important than the design of an
on-line provisioning protocol for the mass-market in spite of
the fact that on-line provisioning is already supplying millions
of e-gov and on-line bank users with certificates in the EU.
Existing schemes (e.g. CRMF) are quite dysfunctional (no PKI
provisioning scheme support PIN policies to take an example)
which has led to the use of proprietary protocols for this task.

OMA-DM: 
I don't think the mobile phone vendors see much value in
creating RFCs for something they have already done.

XML:
I have a hard to envioning a device that can connect to a
wireless network (the sensor you mentioned), and perform
PKI operations but not digest XML.

General Standards Concerns:
I hope nobody mind, but unless you believe there is a value
having your name on an RFC even if it is just collecting dust
on an IETF server, I would start with doing some market
research before taking on a new task.  In such a venture you
would need to identify which vendors that are likely to support
the RFC as well as what organizations that would use it.

Microsoft:
Although I have no expertise in enterprise software distribution
systems like provided by Microsoft, I have a strong feeling
that these can (or could with little extra work), update TAs
in the same way as they can deploy anti-virus updates and
security settings.  PKIX co-chair Stefan Santesson ought to be
able to give some feedback here...

SCVP vs TAM:
PKIX has recently finished SCVP.  It will be quite costly for
vendors of e-mail clients supporting this complicated protocol
(which I at least principally believes addresses a real need).
There is a big risk that the very same vendors will not support
TAM because SCVP essentially solves the "same problem",
although in another way.

That's why I am rather working with on-line key provisioning.
It is already in big use, works pretty bad, is completely non-
standard, and is generally poorly understood.   The 3Bn+ (and
counting) mobile phone users seems to be a market worth considering!

Regards
Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, December 08, 2007 09:08
Subject: Re: TAM is a deal done? Was: TAM as a new WG item?

Hi Anders,

Later,
Max

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Dec 2007 10:42:21 -0500

>connecting to a credible site (the #1 problem on the Internet).

Anders,

OMA is a closed vendor forum, not an open SDO like the IETF. 
Therefore it is not very likely that we would adopt a solution 
developed in such a context.  Also, because the data structure we 
deal with in PKIX are natively X.509, ASN.1 is a preferable syntax 
for defining the TAM model and management protocol.  Finally, anytime 
I hear "registry" I tend to think "Windows," but the IETF is an 
OS-agnostic SDO. Finally, the TAM model offered in browsers is sorely 
lacking, as several folks noted on the TAM list. Thus your comment 
about how this area of the TAM problem being well handled by "... 
various services that the browser vendors supply ..." suggests a 
major disconnect with the sentiments expressed on that list by the 
same set of folks who likely will pursue this work in PKIX.

Since you stated that you have no interest in TAM, please feel free 
to ignore these observations.

Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Dec 2007 08:20:04 -0800

As one of the people who has wanted to close the group for some time I am less worried about this particular extension than others.
 
I have wanted to see the group close because it seemed the only way to get closure on some of the drafts. Now that pretty much everything is in queue and looks set to complete I am not really concerned about that.
 
It seems to me that what we have here is a choice between creating a new group to progress TAM independently and doing it in PKIX. Either way the same set of folk are involved.
 
The only reason for not doing TAM in PKIX is to shut the WG down completely which is going to be a problem until we work out how we are going to manage long term maintenance of cryptographic algorithms and protocols. The IETF model might work at the IP layer where you want finality. But application protocols and in particular security protocols need ongoing maintenance.
 
The W3C has exactly the same problem, as does OASIS.
 
TAM is a three to five year commitment minimum. If we are going to do useful work here we have to face the fact up front. Haste makes for long delays. Every time someone says 'we can't think about that because we are on a tight schedule' I know that its going to take twice as long as it needs to. 
 
Starting TAM in PKIX does not mean having to punt on the maintenance question. Once we get TLS, S/MIME etc over the algorithm agility issues perhaps we decide that both of them plus the bulk of PKIX go off to some new maintenance activity and split off TAM into a different group. It gives us a bit more time to think about it.

What I do have concerns about with TAM is that the use cases and motivating application are not exactly clear to me. I think that in order to get to a useful conversation we are going to have to transpose the discussion into a different domain of application where we all understand the concrete security risks.
 
I want use cases of the form Alice buys a network enabled lightswitch and wants to add it to her network.
 
I have a second reason for wanting to take that approach. Experience strongly suggests that military grade cryptography is much easier than consumer. In military applications you can cover up the deficiencies by ordering people to use it. Sometimes it works and sometimes the director of the CIA gives the key to his study containing all his top secret documents to his cleaning lady...

________________________________

From: [email-masked] on behalf of Russ Housley
Sent: Sat 08/12/2007 10:03 AM
To: Anders Rundgren; [email-masked]
Subject: Re: TAM is a deal done? Was: TAM as a new WG item?

Russ

---

From: "Singer, Michael M (US SSA)" <[email-masked]>
Date: Wed, 12 Dec 2007 11:57:21 -0500

I am in favor of supporting Trust Anchor Management (TAM) as a PKIX work item.
 
Be well.
 
-- Michael Singer, BAE Systems
301-688-2216 (office)

From: [email-masked] on behalf of Stephen Kent
Sent: Wed 12/5/2007 12:46 PM
To: [email-masked]
Subject: TAM as a new WG item?

Thanks,

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Dec 2007 18:31:35 +0000

> able to give some feedback here...

I will come back to the list on this issue very soon. I have a personal opinion but in this case I think I should take my chair hat off and take my vendor hat on and provide a fair assessment of the value of the proposed protocol and I still have some homework to do. But I think I can say that much that Anders do have a point here.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Anders Rundgren
> Sent: den 9 december 2007 00:11
> To: Massimiliano Pala; [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Dec 2007 09:36:43 -0800

Perhaps should have been more concise.
 
I am in favor of adopting TAM as a work item but only if we are going to do the job properly. That means accepting that it is a long term proposition. I don't want a repeat of SCVP that took twice as long as it needed to because the amount of effort required was underestimated.

From: [email-masked] on behalf of Hallam-Baker, Phillip
Sent: Mon 10/12/2007 11:20 AM
To: Russ Housley; Anders Rundgren; [email-masked]
Subject: RE: TAM is a deal done? Was: TAM as a new WG item?

 

 

 

Russ

---

From: "Sharon Boeyen" <[email-masked]>
Date: Thu, 13 Dec 2007 13:43:43 -0500

I support adopting TAM as a work item in the PKIX WG.

-----Original Message-----

At the PKIX meeting this week we hosted a presentation on trust anchor
management (TAM).  The presentation described a rich trust anchor (TA)
model and a management protocol expressed in an ASN.1 syntax.  The model
accommodates three types of TAs, and an authorization scheme for
managing TAs and other signed objects that might be associated with a
crypto module (a hardware or software implementation of crypto
capabilities managed by one of more administrative entities). The
protocol accommodates both online and offline (staged delivery)
management of a module, i.e., it is transport independent and does not
require realtime connectivity.

TAM is obviously of interest to PKIX members, as we make use of TAs for
cert path discovery and validation. However, TAs can be used in more
general contexts as well, e.g., for directly validating signatures on
CMS objects. Moreover, the issue of TA management is potentially broader
than just the X.509 context, i.e., one could imagine developing a TA
model and protocol that deals with other cert types (e.g., PGP) and with
public (signature) keys independent of certs.  Despite the important
role that TAs play in PKIX-based implementations, the WG has never
adopted a work item to develop a model for the management of TAs, nor
specified a protocol for remote TA management.

At the 69th IETF meeting there was a BoF to explore creating a new WG to
pursue development of a TA model and associated remote management
protocol, and a mailing list was established to develop a charter, etc.
Tim Polk has decided that there is not critical mass to create a
separate WG for this purpose. However, Tim is willing to have PKIX take
on the effort as a new work item. If we do adopt this as a work item, we
will focus on TAs primarily in the X.509 context,consistent with the
PKIX charter.

At the WG meeting in Vancouver this week I asked the room if there were
any objections to PKIX adopting this a work item, given that we have
permission from Tim to do so. Two folks voiced objections; both agreed
that pursuing TAM was important, but preferred creation of a new WG for
the task. However, that option is not on the table at this time and thus
is not a subject of the straw poll noted below.

been done already: 

Thanks,

Steve

---

From: max pritikin <[email-masked]>
Date: Tue, 18 Dec 2007 17:57:45 -0600

I am in favor or pursuing this topic.

- max

On Dec 5, 2007, at 11:46 AM, Stephen Kent wrote:
[original message in your archive]