Subject: Re: RE: TAM is a deal done? Was: TAM as a new WG item?

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 12 Dec 2007 13:21:32 +0100

We have a solution for a problem, but nobody agrees on what the problem is.

Could the peole wishing to have TAM accepted, write down what the problems to be solved are ?
Could they provide in two or three sentences what would need to be developed ?

Thanks,
 
Denis

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?

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

At 01:57 AM 12/8/2007, Anders Rundgren wrote:

>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: Carl Wallace <[email-masked]>
Date: Wed, 12 Dec 2007 07:51:07 -0500

> Could the peole wishing to have TAM accepted, write down what the problems
to be solved are ?

The problem statement submitted to the TAM BOF discusses these:
www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement-02.txt

> Could they provide in two or three sentences what would need to be
developed ?

Slide 5 from the PKIX presentation provides a summary of this magnitude:
http://www3.ietf.org/proceedings/07dec/slides/pkix-2.pdf.

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Dec 2007 16:56:13 -0500

If you think there is provisioning work to be done, bring one of the 
referenced protocols to the attention of the WG and see if there is 
interest.  Of course, it would need to be from someone that wants to 
turn change control over to the IETF.

Russ

 > -----Original Message-----
 > 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]
 > 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
 > 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
 >
 >
 > Anders Rundgren wrote: