Subject: TAP

From: "Yee, Peter" <[email-masked]>
Date: Wed, 26 Mar 2003 11:31:06 -0800

Although I believe TAP is a useful addition to the set of tools surrounding
a PKI, I feel that it is further removed from the core PKI functionality
on which PKIX should be working to standardize in this group.  Perhaps a
PKIXEXT or PKIXAPPS working group is merited.

						-Peter Yee

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Mar 2003 10:55:59 +0000

I totally agree with Peter here - the PKIX WG has enough on its plate 
already as is probably evidenced by the tiny amount of time that seems 
to be devoted to "non-core" I-Ds these days, and in any case, there 
may well be more compelling applications on which to work if we were 
to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
chartering PKIXAPPS is the appropriate thing for this community at 
this point). 

Just to mention two possible examples - there is a need for PKI 
support for Diameter and SIP and I don't believe (though I'm open 
to correction here) that such things are getting the level of 
attention in the IETF that they deserve - leaving open (or likely?) 
the possibility that people who want to secure those protocols 
will not use PKI, or will use it badly, or even (heaven forbid) 
start to develop another certificate management protocol! I'm sure
that a PKIXAPPS chartering process will turn up some more such
cases, and probably even more interesting ones too.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Al Arsenault <[email-masked]>
Date: Thu, 27 Mar 2003 08:33:05 -0500

I agree whole-heartedly with Stephen Farrell here.  I think TAP is a
potentially useful protocol.  I don't think it should go into PKIX right
now.  And I think chartering a PKIAPPS working group might be the right way
to go.

                Al Arsenault

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Mar 2003 09:15:04 -0500

Steve:

I do not know what Diameter and SIP are.

If the PKIX is overwhelmed and another group needs to be spun off, that is a
workload issue.

I do see the TAP as more of an infrastructure service in support of
non-repudiation as opposed to an application.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Thursday, March 27, 2003 5:56 AM
To: Yee, Peter
Cc: [email-masked]; [email-masked]
Subject: Re: TAP

Just to mention two possible examples - there is a need for PKI 
support for Diameter and SIP and I don't believe (though I'm open 
to correction here) that such things are getting the level of 
attention in the IETF that they deserve - leaving open (or likely?) 
the possibility that people who want to secure those protocols 
will not use PKI, or will use it badly, or even (heaven forbid) 
start to develop another certificate management protocol! I'm sure that a
PKIXAPPS chartering process will turn up some more such cases, and probably
even more interesting ones too.

Stephen.

"Yee, Peter" wrote:
> 
> Although I believe TAP is a useful addition to the set of tools 
> surrounding a PKI, I feel that it is further removed from the core PKI 
> functionality on which PKIX should be working to standardize in this 
> group.  Perhaps a PKIXEXT or PKIXAPPS working group is merited.
> 
>                                                 -Peter Yee

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Mar 2003 10:01:18 -0500

>cases, and probably even more interesting ones too.

Stephen & Peter,

I think there is a big distinction between the TAP proposal and the 
Diameter & SIP work you suggest. TAP is an infrastructure element, 
potentially supportive
  of a wide range of applications that require archive. SIP and 
Diameter are specific applications. Our philosophy in PKIX has been 
to let each application develop its own profile(s) for use of PKI in 
the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So, 
I would not consider the examples you suggested as appropriate for 
PKIX or for any other PKI-centric WG.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Mar 2003 11:02:40 +0000

Hi Santosh,

> I do not know what Diameter and SIP are.

They are IETF protocols with security requirements which are being
partly met via combinations of TLS, IPsec and CMS but where no-one
(afaik) has really written down how to sensibly setup a PKI. For
example, some Diameter folks were thinking once that a single root 
CA for all ISPs in the world would be a good idea. (Diameter's 
being done in the AAA WG, SIP has various WGs, depending when you 
look.)

I'm sure there are other similar cases in the IETF, those are just 
two with which I'm a bit familiar.

Its a bit like what happened with IKE and PKI and which (I believe) 
held up IPsec interop, and therefore VPN deployment for some time. 

> If the PKIX is overwhelmed and another group needs to be spun off, that is a

I don't believe its only a workload issue, though there are clearly
fewer cycles available to this community when compared to a few years 
ago.

> non-repudiation as opposed to an application.

Sure, I agree with you there. Where we probably disagree is whether 
or not we should add yet more protocols to the infrastructure or whether
we're better off showing people how to use what we've got already. I 
believe the latter.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Mar 2003 10:51:39 +0000

Hi Steve,

> Diameter are specific applications. 

That's true - but I wasn't suggesting otherwise.

> Our philosophy in PKIX has been

Also true, and here's where we probably disagree a bit. I think we'd
be better served by moving focus now away from developing new bits of 
infrastructure and towards helping applications make use of PKI. 

The examples you raise are interesting:

- They're all security WGs!! As infrastructure PKI is much more widely
  applicable
- I think its fair to say they've done a mixed job in terms of
  how well they've managed to integrate PKI and how long it took
- Those groups have fairly good overlap with PKIX in terms of active
  people, which isn't the case generally

All of which tell me that some concerted "PKI help" for (a 
constrained-in-the-charter range of) other WGs/applications/protocols 
might be appropriate at this point.

> PKIX 

I wasn't suggesting PKIX take on those work items. I was seconding
Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
such issues. (Of course, another reasonable approach could be to
try charter a WG to generally tackle key management for a named 
bunch of IETF protocols - that WG could then make PKI and/or 
Kerberos and/or whatever decisions for each such protocol - which
sounds like a good venue for bun-fights, but not much else:-)

> or for any other PKI-centric WG.

A putative PKIXAPPS would be PKI centric and would therefore be an 
appropriate venue for such work.

Stephen.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Mar 2003 12:39:37 -0500

>infrastructure and towards helping applications make use of PKI.

I don't disagree with the need for helping apps make use of PKI. The 
question is whether this should be done in PKIX, another PKI-centric 
WG, or by having PKI experts participate in the target WGs. I'm open 
to suggestions, but we have tended toward the latter, after initially 
adopting the first approach, e.g., we removed extended key usage 
definitions for apps from our profile.

>   people, which isn't the case generally

agree with all of these observations.

>might be appropriate at this point.

That's one approach, but why charter a WG to help these apps, rather 
than asking interested parties to work with the WGs for the apps of 
interest?

>sounds like a good venue for bun-fights, but not much else:-)

That's sort of what I worry about, i.e., trying to solve problems for 
an app requires considerable knowledge of the app, and that knowledge 
is generally held by the app WG.

>appropriate venue for such work.

I am doubtful of this approach, but you should bring it to the 
security ADs if you want to pursue it.

Steve