Subject: RE: Software for PKI

From: Ryan Hurst <[email-masked]>
Date: Thu, 08 Nov 2001 12:00:59 -0800

I see the ROI coming from the benefits associated with unified
authentication systems and ability to manage fewer disparate authentication
technologies. 

I full heartedly agree about the continuous influx of drafts on solutions to
problems that are not well defined and even worse specifications that simply
do not map into any real business need :). I also see us continuously coming
up with new ways to do the same thing which is always fun :). I would
certainly advocate that we add a requirement that there is use case
documentation included with all of these technology drafts.

Ryan

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Thursday, November 08, 2001 9:51 AM
To: Ryan Hurst; 'Mitchell Arnone'; [email-masked]
Subject: Re: Software for PKI

----- Original Message -----
From: "Ryan Hurst" <[email-masked]>
To: "'Mitchell Arnone'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 08, 2001 8:18 AM
Subject: RE: Software for PKI

>
> Mitchell --
>
> The difference is that in many (but not all) cases "knowing that the user
is
> authorized" and "knowing that you have had previous contact with the user"
> is adequate. But even in these cases we still want to know the literal
"who"
> we are doing business with, I think this is more a matter of human nature
> than anything else.
>
> I too think PKI can be a ROI tool, even if we do not take the security
> aspects of the technology into consideration. Building heterogeneous
> authentication infrastructure that is used across organizational and
> technological boundaries has a great potential for return.

Where is the ROI over running a "hardened" computing environment with local
auth models?

The only thing that makes PKI of any real interest to many ifs that it
promises to take the "Human culpability" factor out of most long term
logging or instantaneous decision processes. But I to date have still failed
to see how its going to keep these promises.

This is the problems with allowing people to submit draft after draft on
technologies without require some rudimentary statement about how its to be
used and its constraints, which is why the TS Protocol, for example, is
still undergoing revision after revision.

Why not just mandate User Documents be required before anything is
transferred to a Standards Track? - BTW - take this as an official motion to
the WG as a whole for an amendment to the charter.

Todd

>
> My 2c,
>
> Ryan
>
> -----Original Message-----
> From: Mitchell Arnone [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 4:51 AM
> To: [email-masked]
> Subject: RE: Software for PKI
>
>
> I am not sure I agree with the statement that no one really cares about
> identity.  How can anyone "know what you are authorized to DO" if you are
> not confident that you are who you say you are.  Only after proper
identity
> has been established can proper permissions be assigned.  PKI is all about
> identity management and it may be the most effective method of identity
> management on the market today.
>
> One of our problems is that we have not been selling solutions and that is
> because we have not properly identified the problem.  As a network
> engineer, I became tired and leery of building and supporting so many
> systems and applications with so many IDs and passwords.  I have designed
> and built IP networks, remote networks, VPN networks, Extranets and worked
> with all manner of application integration.  At one point, I had not less
> that 8 IDs and Passwords and it was a costly nightmare.  Companies are
> crying for a solution to this dilemma.
>
> Now consider the alternative.  I have a badge that lets me into my
> corporate building and offices within the building with restricted
> access.  Then that same card permits me to login to the network from any
> workstation in the corporation and permits me access to personal
> information, applications, web pages and so on.   I can justify the cost
> for PKI simply as an effective identity management solution and this
> solution is available TODAY.
>
> This is what attracted me to PKI in the first place and is the primary
> reason for pursuing a career focused on this exciting technology.
>
> Yes ... non-repudiation, confidentiality and data integrity are crucial
but
> until we can deliver a suite of applications that meet those needs simply
> and effectively, we need to focus on those areas where we can derive the
> greatest benefit today.  If we say that PKI is not effective because there
> are not sufficient applications to deliver on these benefits and the
> developers say that they will not deliver these kinds of applications
> because there is no business driver then we will be caught in a Catch 22
> with no way out.  But there is a way out.  PKI is an extremely effective
> Identity Management Tool/Service.  They say that if you develop a better
> mouse trap, people will buy it.  Well we have a great mouse trap right in
> front of our eyes, we just need to sell it, first to ourselves then to
> others.
>
> As more PKI deployments take place, we will be better able to justify the
> business case for application designers to improve upon their efforts and
> to develop more effective applications that will help take advantage of
> these other significant benefits.
>
> PKI and Identity management is a foundation service just like the network
> infrastructure and directories.  You build a strong foundation and
> construct your application architecture in a manner to leverage the
> strength of the foundation.
>
> Lets not underestimate the value of Identity management.  That would be
> like underestimating the value in having a little toe... try cutting your
> little toe off and see how well you walk.
>
> Mitch
>
> At 04:47 PM 11/07/2001, Bob Jueneman wrote:
>
> It's rather ironic that as we are finally nearing the end of the PKIX
> development effort we are beginning to talk about why it isn't being used.
>
> Let me offer my two cents worth:
>
> I believe that we have passed over the peak of technology hype, and are
now
> wallowing in the trough of disillusionment that always follows that kind
of
> crest.  Unfortunately, the collapse of the dot-coms and the rest of the
> economy happened to coincide with the this disillusionment, and 9/11 has
> made matters even worse.  But although it may be difficult to see the
> bright side right now, I believe we will eventually climb out of this, and
> public key technology will be used -- either with or without PKI as we
> presently know it.
>
> 1.  The alleged communications security threat that PKI was envisioned as
> solving simply not perceived to be real.  Most companies just don't have
> any hard evidence that their e-mail is being compromised  -- at least not
> enough to justify implementing end-to-end S/MIME for the average user.
The
> Internet is envisioned by Joe Sixpack as being a dangerous place, but that
> is because of computer viruses and compromised web sites, NOT because of
> eavesdropping.
>
> 2.  Despite the hype and hopes for using PKI for e-commerce,
> nonrepudiation, etc., that hasn't materialized either.  By the time you
get
> through reading all of the fine print behind the CA's policies, plus all
of
> the legal  ifs, ands and buts required to effectively implement
> non-repudiation, you realize that there is no way that a TTP CA could
> really do a bang-up job of due diligence for any reasonable priced
> certificate.  So you might as well negotiate a set of business practices
> with your trading partners directly, and in which case you don't need a
TTP
> CA at all -- you just need his certificates or certificate chain, without
> regard to any particular trusted root. So PKI doesn't scale nearly as well
> as we had hoped it would, primarily because of legal and business reasons,
> as opposed to technical ones.
>
> 3.  Perhaps the biggest single blunder that the PKI advocates committed
> (and I would include myself in that, unfortunately), was to focus
> excessively on the issue of identity.  In business no one really cares
much
> about identity -- on the Internet no one knows you're a dog -- they just
> want to know what you are authorized to DO, and whether you will pay your
> bills.  Identity information provides an easy way to look up that
> information, but is otherwise relatively useless (except perhaps for
audit,
> which no one does anyway).  And identity also collides with privacy, and
> may be perceived as making matters worse, rather than
> better.  Unfortunately, X.509 and PKIX got around to grappling with the
> issues of authorization and rights far too late in the game, with
> mechanisms that were poorly thought out (and remain so to this day) and
> never widely implemented.
>
> In summary, PKI has not failed so much as TTP CAs have failed (at least
for
> end users), and S/MIME has failed  both for lack of a demonstrable threat
> (unless you are a terrorist, in which case you would probably want to use
> steganography rather than cryptography, to avoid disclosing that you are
> doing something that might be suspicious) and because deployment is too
> hard.
>
> On the other hand, PKI has succeeded brilliantly in solving the identity
> problem for SSL, where it is now ubiquitous.  And it has been at least
> marginally successful in dealing with the security issues involved in
> executing downloaded applets, despite the debacle of the bogus Microsoft
> certificate.  And those areas are precisely where the focus on identity
> (and implied rights) is exactly on target.
>
> In addition, PKI has failed because provisioning is too hard, i.e.,  too
> hard to manage.  Going to VeriSign for one certificate at a time is too
> much work and costs too much, but installing something like VeriSign's
> On-Site or the various toolkits available from Entrust or Baltimore
> Technologies takes too much of a leap of faith -- the cost of entry for a
> company is too high.
>
> Finally, another blunder within the PKIX community was in avoiding making
a
> firm commitment to use directory technology to distribute certificates,
> while at the same time not espousing any other workable solution either,
> such as some kind of an http mechanism.  As a result, S/MIME is too hard
to
> use because it is too hard to get your hands on the recipient's
> certificates unless you go through a cumbersome exchange of signed e-mails
> and manually enter them into to your list of recipient's certificates.
> Yuck.  And I won't even mention the problem of managing trusted roots.
>
> Sigh.  "Ve get so soon alt, und so late schmart."
>
> Bob
>
>  >>> "Harrington, Chris" <[email-masked]> 11/07/01 12:20PM >>>
> ***********************************************************
> Mitchell Arnone
> Senior Consultant
> Technical Consulting Practice, Northeast Region
> Schlumberger Network Solutions
>
> [email-masked]
> www.slb.com/nws
>
> 35 Waterview Blvd.
> Suite 210
> Parsippany, NJ 07054-1200
> USA
>
> Phone  +1 410-579-8691
> Mobile  +1 443-838-9373

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Nov 2001 14:12:43 -0800

Thanks for the response Ryan - I agree but this change will take an
amendment of the charter. I would also recommend that all in process works
be required to produce said same use draft prior to be advanced and further
that any drafts or RFC's that seek advancement that do not have the Use
Models defined be refused any further motion.

Todd

----- Original Message -----
From: "Ryan Hurst" <[email-masked]>
To: "'todd glassey'" <[email-masked]>; "Ryan Hurst"
<[email-masked]>; "'Mitchell Arnone'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 08, 2001 12:00 PM
Subject: RE: Software for PKI

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Nov 2001 14:13:37 -0800

anything else belongs in the IRTF and not here.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Nov 2001 13:58:37 -0500

Folks,

IETF working groups produce standards that vendors and users may or 
may not choose to employ. Ultimately, irrespective of whether we 
produce use cases or business cases for the work we do, the 
marketplace will decide if the standards are beneficial and relevant. 
Thus the value of the added documentation burden that Todd suggested 
is not clear. (The inclusion of rationale in standards is often a 
good idea, if it does not make the document too long or too hard to 
read. The PKIX Roadmap document is intended to capture much of the 
rationale and arguments associated with the development of PKIX 
standards. This is more than most WGs do in this respect.)

The IETF imposes certain requirements for advancement of documents in 
the standards process and it is not obvious that the PKIX WG is 
unique in a fashion that requires or motivates deviation from the 
procedures by which the rest of the IETF operates, in this regard.

We make decisions about the potential utility of a proposed work item 
when we adopt the item for the WG, e.g., add it to the charter. This 
decision ultimately rests with the WG chairs, who decide based on WG 
list discussions and based on their experience. I am aware of no 
precedent in the IETF that requires the sort of documentation Todd 
has suggested as a normal part of developing IETF standards, and thus 
I do not envision adopting this proposal as part of the charter for 
PKIX. I submitted the revised PKIX charter to the Security Areas 
directors several weeks ago and when they approve it, it will be 
posted to the IETF web site.

The discussion that has taken place under the subject heading has 
been very wide ranging. Much of the discussion centered on "what's 
wrong with PKI." This discussion often failed to make the critical 
distinction between problems associated with implementations of PKI 
technology, problems with specific PKI models, and problems with PKI 
standards. This WG is not responsible for broken implementations. We 
are not responsible for marketing hype claiming that PKI is a 
panacea. We are not responsible for the ways in which people may 
choose to use PKI technology, which may be a bad fit for their 
businesses. We are responsible for creating standards that are 
technically accurate, comprehensible, and which we believe address 
some non-trivial range of problems associated with reasonable uses of 
PKI technology in the Internet. This is a sufficiently difficult task 
that we are probably well advised to focus on it.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Wed, 14 Nov 2001 01:09:07 +0100

Stephen Kent wrote:
> 
> This WG is not responsible for broken implementations.

I disagree. If a standard is very complicated and features are most
times optional it's difficult too implement it correctly and
complete. Therefore the designers of a security standard are IMHO
indeed somewhat responsible for broken implementations.

Ciao, Michael.

---

From: "Ben Goldman" <[email-masked]>
Date: Wed, 14 Nov 2001 08:20:51 +0200

Hi Steve,

>From my experience in the IETF, the main working group list is meant to
specifically address the rfc issues and to reach a consensus for the
proposed standards. Usually there is an additional, more general discussion
list, where people can freely discuss additional concepts or theories
regarding the marketing, implementation and/or "real life" experiences
involved with the proposed standards.

>From my experience it would greatly help the working group, and reduce the
load in the main list, if we will have an additional list side by side with
the main list. I had checked this issue with our web administrators, and it
would be possible to host this list for the working group.

People can send a subscribe request to
[email-masked]

To Subscribe: [email-masked]
In Body: subscribe your_email_address (In Body)

My 2 Cents.

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Stephen Kent
Sent: Tuesday, November 13, 2001 20:59
To: [email-masked]
Subject: Re: Software for PKI

Folks,

Steve

---

From: "todd glassey" <[email-masked]>
Date: Wed, 14 Nov 2001 08:24:25 -0800

Stephen -

Maybe this is partially my fault - Tim and I spoke for about a half hour
this AM and I perhaps it me that is remiss.

Perhaps what I should have been using is the phrase "Requirements
Specification" rather than that of "Use Models" as I have been.  Tim informs
me in official "IETF-speak" that the "Requirements Specifications" constrain
how this protocol interacts with others and what it actually provides from a
technological perspective, and honestly that is all I have ever wanted to
make mandatory. I agree that it is the responsibility of other standards
orgs to produce end-user use models, i.e. ones in the real world, but that
they cannot do that in most all instances with PKI without that Requirements
Definition.

To that end I would propose that all current in process and future works
including all RFC's and Drafts in play require this addition before being
advanced from where they are as of Today. To that end, I would call for some
discussion and a vote on this matter. Take this as a formal motion before
the floor then.

I move to change the Description Section of the WG Charter by:

    1)    Better describing the functionality of the PKI WG and moving the
bulk of the first paragraph (everything after the first sentence) into a
separate paragraph called "Accomplishments to date:"

    2)    Supply a better description of PKI technologies as the building
blocks of trust (we as a group will have to work on this)

    3)    Supply a process statement within the group about how technologies
are submitted and the operating proviso under which they will be evaluated.

    4)    Supply a Requirements Section statement as part of #3 above.

    5)    Supply an administrative description of the Groups Processes and
Management as well as how it works (or doesn't) with other Standards Orgs
since this is becoming more and more important to PKIX.

Todd Glassey

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Nov 2001 15:14:03 -0500

>indeed somewhat responsible for broken implementations.

Michale,

You are right that the more complex a standard becomes, the harder it 
is to implement, and thus the more likely to be broken. But, what 
constitutes a necessary level of complexity, to accommodate a range 
of legitimate "requirements" vs. what is "excessive complexity" is a 
matter of judgement.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Nov 2001 15:22:09 -0500

>In Body: subscribe your_email_address (In Body)

Ben,

I'm not sure what examples from other WGs you have in mind.

I think the official PKIX WG list, it the right place to discuss 
experience with implementations, etc., since that sort of discussion 
is needed to evolve the standards and if it takes place off list, the 
reintroduction of the discussions into the WG may be harder.

You are right that discussions about marketing do not belong on this list.

By the way, is "security-wg.com" a Cisco site?  I ask since I assume 
you are the same Ben Goldman who is the Cisco product marketing 
manager for security products.

Steve

---

From: "Max Pritikin" <[email-masked]>
Date: Thu, 15 Nov 2001 12:51:26 -0800

Stephen,

I think what is being got at here is how the standards (and thus the
implementations) have been put together. Not what they do.

Imagine that our output is one large book about PKI, asymetric keys,
security etc. There is obviously a lot of really complicated stuff. IF it
was a book like that there would be clearly labeled sections, sub-sections,
appendixes etc. It would/should be possible to read the first couple of
chapters, a detailed section or two and then put the book on the shelf as
reference material. Open most of the good textbooks on your shelf and you'll
see what I mean.

I think what we've produced instead is a very large, very detailed, set of
appendixes. All the information is important (and needs to be available) but
we've failed to present it in an organized and useful fashion. Thus
implementors make mistakes, pieces are not compatible and new PKI
users/developers needs to read/re-read/implement/re-implement a few times
before they have a good feel for what is going on. I think you'd agree that
this reduces the chances for a "killer app" to storm the market, as well as
for any application to be perfect.

Continuing my metaphor we've also failed to find 'straightforward' ways to
get people working with PKIs. Say you were teaching a introduction to
computer programming course. Is your first assignement that students write
an operating system? Or 'hello world'? Even with a good text book one still
starts students with a less complicated task. In the PKI space though we
have not clearly delineated the simple from the complex.

Obviously I'm stretching the boundries a bit here. PKI *is* complex, and
there is no way around it. But we could be looking at ways to make
deployment easier, to make migration easier, to make it possible to ignore
the more complex areas (using defaults, magic or something?) until they are
needed.

That we haven't done this is, I think, where we become responsible for
broken implementations.

	- max

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Thursday, November 15, 2001 12:14 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Nov 2001 16:34:33 -0500

>That we haven't done this is, I think, where we become responsible for
Max,

First, we should distinguish between the documentation requirements 
for users vs. developers.  Each has different needs in this regard 
and one should not expect that the same set of documentation would 
suffice for both.

Standards typically do not include tutorial material, although we do 
sometimes publish such material, e.g., as Informational RFCs.  There 
are many books, seminars, etc. that attempt to educate folks about 
PKI issues, so I do not believe that this sort of educational 
material needs to be a product of this WG. For example, Russ and Tim 
recently published a book on the topic and I recommend that to folks 
looking for PKI background reading.

Standards are aimed at developers, and at a subset of users who make 
decisions about technologies, not "average" users. So, yes, I agree 
that PKIX standards, and those of most other IETF WGs, and of most 
other standards organizations, are not like a textbooks, but I 
disagree with the implied suggestion that they should be.

You also allude to finding "'straightforward' ways to get people 
working with PKIs."  This is definitely not a standards topic.  We're 
not marketing PKI technology.  We're creating standards to facilitate 
secure interoperability among implementations. The PKI Forum is an 
appropriate (non-standards) body to work on literature that 
encourages use of PKI technology, but not PKIX.

There is a legitimate question of what we can do in the standards 
arena to make it easier to deploy PKIs.  This is potentially within 
scope, but only to the extent that it results in specific standards 
consistent with the overall scope of IETF activities. Note that the 
IETF does not standardize user interfaces, and it rarely standardizes 
APIs, for example. We focus on protocols. So, for example, if we can 
define defaults for protocol values, for data structures, etc. that 
one show contribute to easier deployment, that would be a good 
candidate for our standards work. But, we are not defining standards 
for just one market segment, and that makes it harder to create 
standards that are simpler and yet address the perceived requirements 
of all the constituents.

Steve

---

From: "Max Pritikin" <[email-masked]>
Date: Thu, 15 Nov 2001 14:16:46 -0800

RE: Software for PKII was attempting to use a metaphor. I did not mean to
imply that the WG should be producing text books.

Our audience is developers, our product is protocols. But we are still
responsible for presenting and building a protocol (or suite of protocols,
or appendix of data blob formats or whatever) such that it is comprehensible
and usable. And of course it has to be secure, extensible, solve the
security problems at hand, etc. It has to be a system that is buildable.
Many of the details often come from real life development/implementation
needs and we can't ignore that.

I agree that it was a stretch to try and use deployability as an example.
There are interdependencies and complexities that lead to the problems we've
seen in implementations today, and often the complexities that are dropped
(CRL's anybody?) are the parts that are hard to deploy. Since the topic of
this thread has meandered around the issue of PKI software, and I feel
that's languished much because PKI doesn't deploy well, that was the
direction my thoughts have led me.

I also agree that some of these issues are not purely a standards topic. But
what is the use of a standard that can't/isn't being used to its potential?

    - max

  -----Original Message-----
  From: Stephen Kent [mailto:[email-masked]]
  Sent: Thursday, November 15, 2001 1:35 PM
  To: Max Pritikin
  Cc: [email-masked]
  Subject: RE: Software for PKI

    Imagine that our output is one large book about PKI, asymetric keys,
    security etc. There is obviously a lot of really complicated stuff. IF
it
    was a book like that there would be clearly labeled sections,
sub-sections,
    appendixes etc. It would/should be possible to read the first couple of
    chapters, a detailed section or two and then put the book on the shelf
as
    reference material. Open most of the good textbooks on your shelf and
you'll
    see what I mean.

    I think what we've produced instead is a very large, very detailed, set
of
    appendixes. All the information is important (and needs to be available)
but
    we've failed to present it in an organized and useful fashion. Thus
    implementors make mistakes, pieces are not compatible and new PKI
    users/developers needs to read/re-read/implement/re-implement a few
times
    before they have a good feel for what is going on. I think you'd agree
that
    this reduces the chances for a "killer app" to storm the market, as well
as
    for any application to be perfect.

    Continuing my metaphor we've also failed to find 'straightforward' ways
to
    get people working with PKIs. Say you were teaching a introduction to
    computer programming course. Is your first assignement that students
write
    an operating system? Or 'hello world'? Even with a good text book one
still
    starts students with a less complicated task. In the PKI space though we
    have not clearly delineated the simple from the complex.

    Obviously I'm stretching the boundries a bit here. PKI *is* complex, and
    there is no way around it. But we could be looking at ways to make
    deployment easier, to make migration easier, to make it possible to
ignore
    the more complex areas (using defaults, magic or something?) until they
are
    needed.

            - max
  Max,

  First, we should distinguish between the documentation requirements for
users vs. developers.  Each has different needs in this regard and one
should not expect that the same set of documentation would suffice for both.

  Standards typically do not include tutorial material, although we do
sometimes publish such material, e.g., as Informational RFCs.  There are
many books, seminars, etc. that attempt to educate folks about PKI issues,
so I do not believe that this sort of educational material needs to be a
product of this WG. For example, Russ and Tim recently published a book on
the topic and I recommend that to folks looking for PKI background reading.

  Standards are aimed at developers, and at a subset of users who make
decisions about technologies, not "average" users. So, yes, I agree that
PKIX standards, and those of most other IETF WGs, and of most other
standards organizations, are not like a textbooks, but I disagree with the
implied suggestion that they should be.

  You also allude to finding "'straightforward' ways to get people working
with PKIs."  This is definitely not a standards topic.  We're not marketing
PKI technology.  We're creating standards to facilitate secure
interoperability among implementations. The PKI Forum is an appropriate
(non-standards) body to work on literature that encourages use of PKI
technology, but not PKIX.

  There is a legitimate question of what we can do in the standards arena to
make it easier to deploy PKIs.  This is potentially within scope, but only
to the extent that it results in specific standards consistent with the
overall scope of IETF activities. Note that the IETF does not standardize
user interfaces, and it rarely standardizes APIs, for example. We focus on
protocols. So, for example, if we can define defaults for protocol values,
for data structures, etc. that one show contribute to easier deployment,
that would be a good candidate for our standards work. But, we are not
defining standards for just one market segment, and that makes it harder to
create standards that are simpler and yet address the perceived requirements
of all the constituents.

  Steve

---

From: "todd glassey" <[email-masked]>
Date: Thu, 15 Nov 2001 14:12:48 -0800

----- Original Message -----
From: "Max Pritikin" <[email-masked]>
To: "Stephen Kent" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 15, 2001 12:51 PM
Subject: RE: Software for PKI

Stephen,

I WOULD DISAGREE MAX - ITS THAT THE STANDARDS FOR THE MOST PART TALK ABOUT
HOW THEY DO THINGS NOT THE THINGS THAT THEY DO. OR MORE IMPORTANTLY HOW TO
USE THE THINGS THEY DO TO ACCOMPLISH DAILY NEEDS IN THE REAL WORLD.

THIS IS BECAUSE THERE ARE NO REQUIREMENTS DOCS SPECIFYING HOW TO USE EASH OF
THE PROTOCOLS AND WHAT THEY DO AND DO NOT PROVIDE.

appendixes.

ACTUALLY THIS IS A REAL GOOD ANALOGY, ONLY LETS ALSO SAY THAT THERE ARE A
NUMBER OF THESE APPENDICES WHO's SUBJECT MATTER IS NOT INTEROPERABLE WITH
EACH OTHER AND IT IS NOT ALWAYS CLEAR WHICH IS WHICH.

All the information is important (and needs to be available) but
we've failed to present it in an organized and useful fashion.

AMEN.

Thus
implementors make mistakes, pieces are not compatible and new PKI
users/developers needs to read/re-read/implement/re-implement a few times
before they have a good feel for what is going on.

DONT FORGET THE ADDED AMOUNT OF TIME IT TAKES TO COMPLETE ANY PROJECT SINCE
EACH FUNCTION HAS TO BE ARGUED OUT SINCE THERE IS NO INTENTION STATEMENT AS
TO WHAT ITS SUPPOSED TO DO FOR THE BIGGER PICTURE.

I think you'd agree that

Continuing my metaphor we've also failed to find 'straightforward' ways to
get people working with PKIs.

Say you were teaching a introduction to

OR MAYBE JUST BUILD SOME USE MODELS SO THAT WE CAN UNDERSTAND THE COSTS OF
DEPLOYINNG IT. AND ITS BENEFITS ONCE DEPLOYED.

- max

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Nov 2001 17:28:33 -0500

At 2:16 PM -0800 11/15/01, Max Pritikin wrote:
>I was attempting to use a metaphor. I did not mean to imply that the 
>WG should be producing text books.
>
>Our audience is developers, our product is protocols. But we are 
>still responsible for presenting and building a protocol (or suite 
>of protocols, or appendix of data blob formats or whatever) such 
>that it is comprehensible and usable. And of course it has to be 
>secure, extensible, solve the security problems at hand, etc. It has 
>to be a system that is buildable. Many of the details often come 
>from real life development/implementation needs and we can't ignore 
>that.
>
>I agree that it was a stretch to try and use deployability as an 
>example. There are interdependencies and complexities that lead to 
>the problems we've seen in implementations today, and often the 
>complexities that are dropped (CRL's anybody?) are the parts that 
>are hard to deploy. Since the topic of this thread has meandered 
>around the issue of PKI software, and I feel that's languished much 
>because PKI doesn't deploy well, that was the direction my thoughts 
>have led me.
>
>I also agree that some of these issues are not purely a standards 
>topic. But what is the use of a standard that can't/isn't being used 
>to its potential?
>
>     - max
>
Max,

We are in agreement that feedback from implementation and deployment 
experiences represents valuable input to the standards process. But, 
we already do that. For example, changes were made to CMP based on 
interoperability testing that was reported in PKIX meetings and list 
postings. Frequently we make changes to a standard based on this sort 
of feedback, which is why the IETF requires multiple interoperable 
implementations prior to approving the progress from Proposed to 
Draft status.

You ask "But what is the use of a standard that can't/isn't being 
used to its potential?" The question before us is not that; rather it 
should be what role can this standards group play in helping PKI live 
up to its potential, given the scope of IETF standards activities? 
Constructive suggestions relative to that question are welcome.

Steve

---

From: Tim Polk <[email-masked]>
Date: Thu, 15 Nov 2001 17:43:44 -0500

Todd,

I'd like to respond in two parts - first on requirements documents and 
second on the charter.

                                         Requirements

I do agree that requirements specifications are generally a good thing.  I 
believe that DPD/DPV is an excellent example of where a requirements 
specification makes the difference between technical specifications that 
cycle at draft and specifications that achieve RFC status.

However, we are not entirely in agreement about the the scope of a PKIX 
requirements document.  I may have mis-spoke when we were on the phone, but 
the requirements document does not "constrain how this protocol interacts 
with others".  PKIX is a service provider, not an application.  Protocol 
designers and application developers are free to use our specifications to 
meet their security requirements.  I agree that it is imperative that they 
understand "what it actually provides from a technological perspective".

This information permits the protocol or application developer to build a 
"use model" that makes sense in their environment.  The appropriate use 
depends on due diligence for an industry or sector, legal requirements, and 
the threats and risks associated with a particular application of the 
technology.  As a result, there is no way that PKIX can describe 
appropriate "use models".

However, not all specifications need a requirements document.  The PKIX 
algorithms specification is a perfect example: the scope and utility of the 
specification are straightforward.  There is no utility in a requirements 
document for that specification.  (The PKIX LDAP schema is another such 
example.)  A blanket requirement for requirements drafts will only slow 
down progress, and *we can't afford to go any slower*.

                                     Charter

I do not believe the charter modifications are appropriate or 
required.  Steve and I recognize the utility of requirements documents, and 
the scope where they are useful.  The IETF has a flexible process that 
allows the chairs to make decisions on a case-by-case basis.  When it is 
appropriate, we can insist on a requirements document as a prerequisite for 
progression of current documents or submission of new WG documents.  When 
requirements documents are not needed,  we can streamline the process.

The IETF is not a "formal standards body" with motions, votes, and detailed 
processes.  That is a feature, in my opinion.  I believe that flexibility 
is critical, and oppose any changes to the charter that reduce that 
flexibility.

Thanks,

Tim Polk

---

From: "Ben Goldman" <[email-masked]>
Date: Fri, 16 Nov 2001 03:17:07 +0200

Hi Steve,

The sake of having an additional "think tank" list is done for one reason
only, to move the general, more theoretical discussion off the main list. As
we share the same interest that PKI will be finally massively adopted, we
must enable some informal discussion on how to adopt this technology in the
real world.

For example, the isle talks at the IETF meetings are more general than the
formal working group discussion, yet these discussions have a crucial part
to the success of the standard/technology.

One example for such an additional "general" list could be diffserv. In
diffserv, the additional "implementation" list has greatly "load balanced"
the main list.

Have a look at http://www.atnf.csiro.au/news/exploders/dsimplementation.html

As you might know, maintaining an IETF list is quite a task, cleaning it up
once in a while, filtering spam etc. and it's not a fun job one would like
to have. I have started this list in order to reduce the load of the main
list, as you described in your message (and I totally agree). Since I had
received numerous requests to subscribe to the list, I believe there is a
demand for such a group. If it won't work we can always kill it.

I would be happy to get the feedback of other participants in the working
group in order to get other's opinion. If it works well in other groups it
might be good for us as well.

Regards,

Ben

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 22:22
To: Ben Goldman
Cc: [email-masked]
Subject: RE: Software for PKI

Ben,

Steve

---

From: Michael Ströder <[email-masked]>
Date: Fri, 16 Nov 2001 12:31:47 +0100

> of legitimate "requirements" vs. what is "excessive complexity" is a

Stephen, your answer is very diplomatic and leaves room for every
interpretation. So all of us are right and we all can feel cozy and
warm...

I don't want to offend anybody personally but I feel the need to be
more concrete and a little bit harsh on this:

I'm observing that this working group (and other PKI-related working
groups) most times discusses how to avoid the key word MUST for the
sake of flexibility. Note that every use of key words SHOULD, MAY or
ASN.1 key words OPTIONAL, DEFINED BY, CHOICE etc. causes an extra
need for defining the concrete semantics in a certificate profile
and an extra if-elif-else statement in an implementation. As we
experience today this is very error-prone and unsecure process and
raises costs of PKI deployment dramatically.

IMO simplicity is a crucial prerequisite for security. Therefore a
security standard has to define almost all features/aspects as
mandantory.

Today it has absolutely no meaning that an application is compliant
to PKIX because the room of interpretation of PKIX "standard" is so
wide. It's kind of absurd that this WG - the protocol designers(!)
itself - are reviewing a statement of Microsoft what *they* think
what PKIX compliance of their product means. You should not have to
wonder what "PKIX-compliant" implementation come out of *your*
standard. You have to know it in advance! And a PKIX vendor should
not have to write a statement about his PKIX implementation. It has
to be sufficient that the vendor is PKIX-compliant (tested by a
well-defined test suite checking the mandantory features).

RFC 2459 was published January 1999. Frankly since then I can't see
any added value of PKIX over X.509v1. There's not a single X.509v3
extension defined in PKIX a PKI designer can really rely on. For
each and every extension somebody planning/deploying a PKI has to
check each and every implementation if and how this implementation
interpretes this extension. This is WEIRD!

Now I don't think that the folks working on XML-DSIG and XKMS are
really doing it better. There's also the tendency to be most
flexible by integrating as many PKI standards as possible. Same old
problems...

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 16 Nov 2001 12:35:48 +0100

> DEPLOYINNG IT. AND ITS BENEFITS ONCE DEPLOYED.

Yes!

Ciao, Michael.

---

From: "Jean Pawluk" <[email-masked]>
Date: Fri, 16 Nov 2001 10:03:47 -0800

Ciao Michael

 RIGHT ON !

 PKI is at a critical point where either it has to be made to work
coherently, securely
 and in a relatively simple fashion or the community of interest will
abandon it for other approaches

        interprets this extension. This is WEIRD!

Yes it is and very expensive and time consuming! Some goodness has evolved
out
of all these additional changes but it is dammed hard to keep track of. .

"We have meet the enemy and he is us" is an apt quote. Of course
the many other standards group that are related also add to the confusion.

While I wouldn't rather have that root canal, it looks a lot less painful at
times
than using PKI.

Regards
Jean

---

From: "todd glassey" <[email-masked]>
Date: Fri, 16 Nov 2001 13:42:49 -0800

Tim, I rewrote this acouple of times before sending it. Here goes the last
version -

----

Tim, in a nut shell you have codified everything that is broken here in the
PKIX WG. The ability to veto anything is something that you and Steve both
use way too often and it needs to be removed immediately. Further based in
your commentary below the WG Chairs roles need to be formally defined and
added to the Charter proper.

Bluntly, you need to be accountable for what PKIX is and has grown to under
your leadership, especially the disarray and in-fighting between the various
commercial factions that need their standards advanced.

As to your rebuttal below - I believe that you are wrong across most all of
your points. And in fact I would put forward that you as a WG Chair shoud
not be able to make political decisions for the Group without consulting the
membership base.

Your role is actually as a facilitator and a keeper of focus. But you dont
get to decided what the focus is on, just that there is focus and work
continues to flow. The one constraint you get to exercise is a veto if the
subject matter or focus is not in the PKI Vein - Nothing more nothing less.

And to this focus we were talking about in the last paragraph, the subject
of the focus is up to the membership of this WG as a whole or to its sub
groups where qualitfyable pockets of interest exist. That means that this WG
MUST promote **all** proposals and protocols submitted to it whether it
favors them or not. If they meet the filing format requirements, it is
unreasonable that You or Steve should have anything to say as to whether
they are promulgated from Draft to RFC and then from RFC to Standard.

In fact there is a serious issue here as many of the standards the PKIX
group works on having real value so this veto power as you have used it
could in some instance potentially constitute restraint of trade and that's
a serious problem.

To fix these problems we need the amendment to the Charter as well as a
formal description amendment to the Working Group Chair's definition.

We also need the ability to talk to people about what our protocol modules,
methods, and schemas do in theoretical and real-world senses. If we cant do
that how can anyone build something that is reliant upon one of these
models. It would be like trying to nail Jello to the wall. So we need
Requirements Documents and Use Models where applicable.

Todd

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Nov 2001 14:59:44 -0800

At 1:42 PM -0800 11/16/01, todd glassey wrote:
>Further based in

That is, of course, unnecessary. The role of WG Chairs in IETF WGs is 
well-defined in RFCs 2026 and 2028. In addition, the appeal process 
for those people who feel aggrieved is also clearly laid out in RFC 
2026. You may want to read these RFCs and follow them instead of 
asking that the PKIX WG act any differently than the other WGs in the 
IETF.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "todd glassey" <[email-masked]>
Date: Sat, 17 Nov 2001 13:24:22 -0800

Paul,
For one thing PKIX is unlike any other WG in this IETF so your commentary
about making PKIX different is almost funny. It already is.

As to the references you cited - thanks for opening that can up. Excerpts
from both documents, the RFC2026 Standards Process and the RFC2028
organizational models from circa 1996 are included. But the real funny part
is that the WG Chair is actually described in an even more arcane document,
from 1994 called RFC1603. And guess what - It actually constrains the WG
Chair's role pretty well with the exception of the issues listed below in
the proposed changes to how this WG operates.

So in answer to your push-back -No, Paul the changes to the Charter are
necessary the world has changed over the last 8 years quite a bit. The
motions before the group stand. As to the justification, try #1 and 2 below
and to the motions themselves, try #3.

-----

    1)    RFC2026 and 2028/1603 do not say that they are the totality of the
WG and WG Chairs definitions. RFC2026 is the RFC process and they are a
starting point and like the IETF's other general purpose charter's were
intentionally left vague in many sections so that they would be open to
interpretation.  In fact they are specific about being left open to some
level of  interpretation. But they are also particular to playing fair.

RFC2026 Fragment:
<!--StartFragment-->
   o  These procedures provide a great deal of flexibility to adapt to
      the wide variety of circumstances that occur in the
      standardization process.  Experience has shown this flexibility to
      be vital in achieving the goals listed above.
<!--EndFragment-->

This is further reinforced by the WG Chair's responsibilities in RFC1603 and
the lack of any formal statement that a working group chair may shut down
any standard track efforts or other filings.

RFC1603 Fragments
<!--StartFragment-->5.1. WG Chair

   The Working Group Chair is concerned with making forward progress
   through a fair and open process, and has wide discretion in the
   conduct of WG business.  The Chair must ensure that a number of tasks
   are performed, either directly or by others assigned to the tasks.
   This encompasses at the very least the following:

<Compressed List from 1603 of WG Chair Responsibilities>
   Ensure WG process and content management
   Moderate the WG email list
   Organize, prepare and chair face-to-face & on-line formal sessions
   Communicate results of sessions
   Distribute the work
   Document development
   Document publication

The terms wide-latitude do not include deciding what is done in the group
without accepting legal liability for said same. Do you and Tim accept this
liability? And which one of you moderates the List? or is that Paul?

As to PKIX itself - PKIX is unlike any other WG here in the IETF and its
standards have had direct consequence on the development and distribution of
PKI wares in the commercial industry on a global basis.

Further, these tools are not built to be used in operating the internet, or
in routing or any other core networking function. They are services to be
used as part of decision support processes and event management mechanisms
across a network transport or distributed topology or atop a single machine
instance. They form the basis of TRUSTED SERVICES in these environments if
used properly. So while they are network-capable they are not necessarily
tied to any one networking model. In fact its questionable as to whether
PKIX even satisfies the statement of qualified topics for standardization in
RFC2026.

Again - What they, the deliverables of PKIX, are about is in operating TRUST
PROCESSES and that has nothing to do with anything the technical IETF would
have any reason to look at. We are not talking about transport
authentication here in PKIX or timestamping as part of a transport for
information assurance audit or anything like that. We are talking about the
commercial use of x509 certs at the applications level and unfortunately for
the IETF this does have  real dollars attached to it.  So PKIX not only is
not a network process - it's "commercial service primitives over a
decentralized topology model" with liabilities to a number of commercial
standards orgs and processes.

Lets also look at the following excerpt from the opening commentary of
RFC2026
<!--StartFragment-->
   The goals of the Internet Standards Process are:
   o  technical excellence;
   o  prior implementation and testing;
and here is the biggie -
   o  clear, concise, and easily understood documentation;
That's the one I was looking for. Intentionally violating this by refusing
to add a use-statement or requirements-statement contravenes one of the
filing standards and so every PKIX work to date needs to have these added or
be recalled.

The list continues too
   o  openness and fairness;  and
   o  timeliness.

This means as far as I can tell that the WG Chairs have nothing, I repeat
NOTHING to say about what is submitted or its advancement. They may have
much to say about the submitters failure to advance their own works but that
is because they have their own milestones.

Their role (The WG's)  is to act as caretaker and to make sure that the
standards efforts proceed forward. It also means that the IESG has no other
role than to make sure all the requirements are checked off on any
Standard's Submission. Otherwise the fair play language is just rhetoric,
and that likely would be actionable in both Civil and Federal Court here.

    2)    Steve/Tim - On of the retorts you used is that it is the
Commercial World's responsibility to figure out how to use PKI wares , my
response is that based on the above excerpts from 2026 and 2028/1603 that
this also is a bunch of hogwash.

That clear and concise requirements doesn't mean "easily understood by the
writer" that means easily understood by someone else trying to judge the
usefulness of the protocol or to use it.

...And I have to wonder why you would say that there is no need to
communicate a use model or requirements as part of being clearly understood?
Which gets us back to that burning question about why we, PKIX. Is this just
Art for Art's sake - because if it is it belongs in the IRTF and not here.

Anyway - Steve  - I think you and Tim need to answer #3d below as an
exercise and tell us as the WG, what you intend to do as its management to
meet these needs and the expanding role of PKIX under your hand. I as a
group member certainly have a right to ask this.

---

    3)    The current Charter needs to be amended to reflect the extended
requirements (over those cited in RFC2026 and RFC2028/1603) of this WG's
operations including:

            a)    adding end-use or interface requirements and operational
models of how to use our PKI efforts (almost like the "preferred modus
operandi" section of a patent) - Even if its just a paragraph or two
describing the creators intents behind a protocol's use. This cant take more
than a few hours to write and so the commentary regarding this will slow the
Process Down is garbage.

            b)    Also, it is clear at this point that we need a way to make
changes in the management process when the group deems it is valuable to do
so. And these need to be changes specific to PKIX, So the Charter needs to
be amended that we will use the existing RFC's as a basis of our operations
and policies models with our own additions that are specific to this WG.

            c)    And personally that monster opening paragraph on the
charter page needs to be whacked - The charter in its place needs something
more about why this group exists - Something like "to conceive of standards,
methods and schema and promote the use of those for PKI in distributed or
networked topologies. Myself - I believe that this means at the very least a
statement of interoperability and interactivity. That material that was
excised form the opening paragraph belongs in the Milestones/Accomplishments
Sections of this WG.

            d)    and a WG Chair Review process wherein the Chairs have
their own specific goals to achieve within the WG. This is the only way to
judge how successful any management person is . Set some milestones.

----

Look, this WG has produced a tremendous amount of work product and under
your hand has grown to where it is now, but it needs more that what you have
put into it. it needs to embrace interoperability and formal processes for
insuring such. It also needs to extend its focus beyond the IETF, something
the IETF's charter really never looked at, since the world has changed.

You may not like these words, you may feel they are a shotgun approach to
the growing pains this group has been going through, and you may not like
that this is not the IETF of  1990. But I think its time to stand up and be
counted. Its time for PKIX and its management to be accountable.

Todd Glassey

----- Original Message -----
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 16, 2001 2:59 PM
Subject: Re: Motions before the WG - Was Re: Software for PKI

> well-defined in RFCs 2026 and 2028.

Which WG radified these standards Paul -

> In addition, the appeal process
> 2026.

And it is insufficient for the operations of this WG.

> You may want to read these RFCs and follow them instead of

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 17 Nov 2001 19:47:02 -0500

> 1602 The Internet Standards Process -- Revision 2. Internet
>     Architecture Board and Internet Engineering Steering Group. March
>     1994. (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by
>     RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL)

> 1603 IETF Working Group Guidelines and Procedures. E. Huizer, D.
>     Crocker. March 1994. (Format: TXT=63900 bytes) (Obsoleted by RFC2418)
>     (Updated by RFC1871) (Status: INFORMATIONAL)

> 1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November
>     1995. (Format: TXT=7747 bytes) (Updates RFC1602, RFC1603) (Also  
>     BCP0002) (Status: BEST CURRENT PRACTICE)

> 2418 IETF Working Group Guidelines and Procedures. S. Bradner.
>     September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Also  
>     BCP0025) (Status: BEST CURRENT PRACTICE)

---

From: Tim Polk <[email-masked]>
Date: Mon, 19 Nov 2001 18:41:12 -0500

Todd,

The WG chairs cannot prevent you or anyone else from submitting an 
Internet-Draft.  Anyone can submit an I-D at anytime.  However, IETF 
procedures *require* that the WG chair approve processing of new 
specifications as WG documents.  That is, if someone submits 
draft-ietf-pkix-newprotocol-00.txt, the PKIX chairs get a message asking if 
this really is a working group document before the document is posted and 
the WG website is updated.

This is a very important feature of the process.  An IETF working group 
cannot support development of an infinite number of specifications.  By 
limiting the number and vetting the topics, we ensure that the WG has 
sufficient resources to meet the most pressing needs.  Progression of our 
existing documents is our first priority (and that of the Security ADs).

Steve and I don't decide which specifications to approve based on 
politics.  That is hogwash, and I totally resent that accusation.  We do 
our best to make the determination a solid engineering decision.  Some of 
the questions we ask are:

* What does this specification add to the PKIX standards suite?  For 
example, we already have two certificate management protocols.  A third, 
fourth, and fifth will only add confusion.

* Is there a community interested in working on this specification?  If the 
only one who is interested in working on this topic is the editor, it 
shouldn't be a WG specification.

* Is there a community that wants to use this specification?  If another WG 
has identified a requirement, that is a compelling reason to work on it.

* If there are competing proposals, which proposal is *technically* 
superior?  If you recall  the SCVP/OCSP v2 debate, arguments based on 
marketing concepts (e.g., people already know the name "OCSP") didn't 
fly.  Steve pushed for requirements documents to evaluate the utility of 
each protocol on a technical basis, and state diagrams to evaluate efficiency.

* Note that commercial considerations are not an issue.  You wrote about 
"the various commercial factions that need their standards advanced." I 
assume they need the standards to be advanced to sell products and obtain 
funding.  That's marketing, not engineering.  I'm sorry, but that isn't the 
mission of the IETF.  We are supposed to be creating standards that support 
"the evolution of the Internet architecture and the smooth operation of the 
Internet."

Steve and I do not make these decisions in a vacuum, either.  The group has 
opportunities to weigh in, and authors have several strategies they can use 
to get a document accepted.  If a document clearly addresses an important 
problem within our scope, it may be accepted immediately.  More likely, the 
editors are asked to demonstrate that the problem is important and that 
people want to work on the topic.

One tried and true method for getting a document into the WG is to publish 
an independent I-D and bring it to the attention of the WG list.  If a 
community of interest emerges on the list, then the document is likely to 
become a WG specification.  There are a number of examples of this process 
succeeding in PKIX.

Even if the document does not become accepted as a WG document, the author 
can progress the document.  It can still become an RFC without any WG 
affiliation.  There are a number of examples of this as well.  (I think RFC 
2313/PKCS #1 is one, but you can't hold me to that.  I wasn't there.)

You suggest that the role of the chairs is "facilitator" and "keeper of 
focus", yet you demand that any document that meets the "formatting 
requirements" of an I-D has to be accepted as a WG specification.  That 
makes no sense!  Vetting proposed I-Ds is the one of the most important 
aspects of keeping that focus.  (Another is establishing requirements 
specifications for complex or controversial protocols, like DPD/DPV.)

If anything, Steve and I have been *too liberal* with approving 
documents.  The PKIX WG currently has twenty one I-Ds.  How many documents 
do you really think the WG can support?

You also say that we must be held accountable for "the disarray and 
infighting between the various commercial factions".  I guess that's true 
in part.  We are trying to require that documents progress based on 
technical qualifications, and not progress multiple specifications that 
meet the same requirement.  I suspect that does cause commercial factions 
with competing specifications to fight.  However, if we approved every 
draft and sent them on the ADs, there would be a great deal more confusion 
and disarray!

Well Todd, I don't know what to tell you. I'm not convinced by your 
arguments. On the other hand, you didn't find my first rebuttal convincing, 
and I expect this one won't satisfy you either.

Tim

---

From: "todd glassey" <[email-masked]>
Date: Tue, 20 Nov 2001 16:33:25 -0800

----- Original Message -----
From: "Tim Polk" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Sent: Monday, November 19, 2001 3:41 PM
Subject: Re: Motions before the WG - Was Re: Software for PKI

> specifications as WG documents.

Unfortunately this puts the WG Chair in the position of being liable for
squashing someone's technical standards efforts and that may have
real financial consequences. Which is a serious problem. The IETF
was founded to be an open standards org and that means open,
for all! Not just who you decide on.

> That is, if someone submits
> cannot support development of an infinite number of specifications.

Yes it can, and it really has no choice. As I said above your approving
specific technologies, 1 over the other, puts you in a position where
propriety is impossible. You cannot run from the fact that PKIX
standards in particular are only of use in commercial and legal
processing models. What else would anyone want PKI for?

> By

And those teams are working fine. Your problem is that you cannot suppress
another effort - it will escalate - and neither the IESG nor the IETF is
going to want that type of heat.

> politics.  That is hogwash, and I totally resent that accusation.

But the point is that you have no right to make any decisions on
one protocol versus another. Noting in the charter says so.

> We do
> our best to make the determination a solid engineering decision.

here again man, do you think you are a VP of Engineering and
that you have a limited amount of engineers for your projects???
get a grip - you are a Working Group Chair and I and every
other member of this WG has the right to submit protocols and
get them advanced.

> Some of
> * What does this specification add to the PKIX standards suite?

The IETF is not here to only standardize one protocol, take routing
protocols for instance - how many core routing protocols are there? RIP,
RIP-II, BGP OSPF, etc etc etc.

The point is that what being a WG Chair is about. being a facilitator
Not a Czar.

> For

BS. - if there was a simple requirement for interoperability statements, and
requirement statements there would be no issues because it would be clear
what each protocol component did.

How can anyone do a standard  without an external reference specification?

> shouldn't be a WG specification.

Unfortunately a community may be as few as ONE I think.

> superior?

Not your call - are you and auditor in the role you sit in now?

>  If you recall  the SCVP/OCSP v2 debate, arguments based on

That's because this group is constrained erroneously that "there is to be
only one way of doing things" in PKIX and that to a large part **is** the
current management team's fault and that needs to be changed.

> mission of the IETF.

OK - So if you as an employee of Company A, and a WG Chair,  see that
Company B is submitting a new standard and they need a protocol to be
developed in a WG so that others can see its value, but you again as Company
A's employee see that to be a bad thing for your company - how does that
effect the role of impartiality -

The problem we face here is that whether  we like it or not these standards
have extreme value in a commercial sense so your refusing to embrace or
advance a standard effort may have real civil damages attached to it.

> We are supposed to be creating standards that support

No, You are supposed to be working on Open Networking Standards.

And as to the IETF's focus, the actual Internet does not use that many of
the IETF's protocols relative to the total number of protocols that the
IETF's WG have created. They are inappropriate for the backbone. What has
happened is that under the Guise of "Working on the Internet" the IETF has
swollen to encompass lan, wan, and man protocols as well as those from
applications and methods of moving data wireless.

So the IETF has long since morphed itself into *** Global Networking
Standards Org***. If anything the ITU is the true Internet Standards Org at
this point.

>
> Steve and I do not make these decisions in a vacuum, either.

But Tim - one key point is that is defined as "wide latitudes" is just
that - undefined.  And that for a WG Chair is unreasonable. Someone sitting
in the role of the WG Chair is not a Czar choosing which peasant lives and
which one dies.

> The group has

Except that the Drafts don't usually contain any of this justification, or
we
would not be having one part of this conversation.

> become a WG specification.  There are a number of examples of this process

And here again the WG itself has no business refusing to advance any
protocol draft. Any draft submitted must be advanced if it meets all the
requirements.
> requirements" of an I-D has to be accepted as a WG specification.

Tim, logically what do these two concepts have to do with each other? The
first is regarding whether or not the WG Chair should be accorded
unrestrained or constrained power to do as they please, and the second is
regarding whether or not the functional plumbing of the RFC process must be
accorded in the WG as well for all submittals or just the ones the WG wants
to work on.

You talk about community in this retort but I am willing to bet that a court
would define that a community can be as few as one. And if that's so by
virtue of the fact that it was submitted the material MUST be advanced
within the WG structure.

> That
> aspects of keeping that focus.

yes and no. Vetting ID's is about collaboration on a set of multiple uses
for any given effort within the IETF but often without a constraint to guide
this effort, too many slight orthogonal uses pop up and every body take a
slightly different tack at the collaboration. What this does is create a
tremendous amount of noise and chaos in any design process.

> (Another is establishing requirements

Yes I agree to that

> documents.

Ahahhahahaha - you make me laugh.

> The PKIX WG currently has twenty one I-Ds.  How many documents

As many as are filed. I don't think you have a choice here. If the term
community can be construed as few as one, then this WG must take any
documents submitted. This is not a political organization voting on what
becomes an embraced standard. Anything that is submitted must be advanced if
it meets the processes requirements.

What I do think that you should do is to get working plans form anyone that
plans a standards submission. That you layout the process of satisfying the
document process requirements and figure out as to whether discussion is
needed. This needs to be documented and available to the group as a whole.
Maybe on the website.

> in part.

My apologies - I didn't mean to sound like an ass and I don't hold you
personally liable for the infighting per se. PKIX is an unruly bunch
anyway. What is true is that times are changing and critical
interoperability is something that this group has not achieved. Do I think
that a more open collaborative and accepting environment would have changed
that - yes, to some extent, but as I said to Paul offline, I am not
interested in replacing either of you. I just want the two of you 'out of
the kitchen' so to speak and into more administrative roles.

> We are trying to require that documents progress based on
> meet the same requirement.

here again - you personally are not the arbiter of what is done and what
isn't.

>  I suspect that does cause commercial factions

That's Jeff and Marcus' problem. If PKIX is too much for them they can get a
third AD or sluff off some of the more stabilized WG's to other AD's.

> and I expect this one won't satisfy you either.

 You're right - but Tim as I said in the call I left  for you today, I am
not out to cream PKIX, but I am personally one of those people that has
suffered on the commercial side because PKIX refused to vet a particular
technology. One I personally believe is superior to the TSP that is what
this WG is currently pushing.

The problem is that whether PKIX likes it or not it has a role to play and
that role, I believe is now morphing to provide more support at the
Applications Layer. PKI technologies need to be made interoperable and we
need to have simpler manners of using them. And Mostly we need to really
understand what they do and don't do in trusted computing, especially from
an Evidentiary Model since that's where a large amount of the commercial
focus of PKI will be.

These are failings in the management of the group but their addressable. The
issue regarding the scope of the WG Chairs powers and authority is also a
separate issue, however one that needs addressing here. To these ends the
motions stand.

Todd

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 21 Nov 2001 09:52:27 -0500

>for all! Not just who you decide on.

This is simply not the case.  People are always free to post their document 
as an individual contribution and send a message to the working group mail 
list asking for review.  If there is sufficient interest, then a subsequent 
revision of the document can be posted as a working group contribution.

If this approach fails, anyone can approach the Area Director and request a 
BOF.  If the BOF generates sufficient interest, it will result in a working 
group with an independent charter.

Russ

---

From: "todd glassey" <[email-masked]>
Date: Wed, 21 Nov 2001 07:11:55 -0800

----- Original Message -----
From: "Housley, Russ" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 21, 2001 6:52 AM
Subject: Re: Motions before the WG - Was Re: Software for PKI

> revision of the document can be posted as a working group contribution.

I am sorry Russ - it is exacrtly the case. And a draft filed in some other
WG simply does not have the same public perception as a Draft and RFC
brought up through the PKIX WG Process.

> BOF.

Who always has the option of saying no.

> If the BOF generates sufficient interest, it will result in a working

No - If the BOF has sufficient interest AND a significant number of people
push the IETF to creat a new WG after the BOF, it, the IETF, may, depending
on what it is up to at any instance, create a new WG or it (the IETF/IESG)
may say no. But what does having a new WG created have to do with the issues
at hand - that being that

    1)    That PKI Drafts and RFC's currently have a provable value in the
marketplace. And as such any draft submitted should be advanced whether the
WG Chairs like it or not, all the Draft or RFC needs to do is to fulfill the
requirements of being vetted inside its community of supporters. Then the
issue of whether a committee can be one person needs to be resolved.

    2)    ThePKIX WG Chairs roles need to be constrained so there is more of
a statement as to how they add value to the process and what this WG is
going to do to add value to its efforts.

   3)    The output of PKIX needs to be better defined. I have never seen a
formal networking or SW standard from any other Standards Org that did not
have a real "reference specification". Especially an External Reference
Specification. After all  - how would you know how to use it. But moreover
they, our efforts, need a section on the thoughts and vision of the creators
as to what this protocol is supposed to be used for - i.e. whats the general
idea.

Lets take the TSP for instance - Can you with the documents currently on
file come up with a use model that anyone would want or need to deploy? - I
don't think so.

T/

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 21 Nov 2001 10:52:12 -0500

>brought up through the PKIX WG Process.

What individual contribution was posted?  Can you give the URL to the 
message in the working group archive that requests that the working group 
consider it?  Did it result in a discussion?

We have used a lot of time on veiled concerns.  Please present the specific 
case where you feel that the chairs stifled consideration of a particular 
protocol.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 22 Nov 2001 16:40:43 +0100

Todd,

As Carlisle said: "I've told myself multiple times not to jump into this
thread, and I refuse to get dragged into a long back-and-forth discussion."

So I will not jump for long and I do not have enough time available 
(as you seem to have) to sustain long discussions.

Your criticisms to the co-chairs are hidding a point which is major to you 
only. 

> (...)  I am personally one of those people that has

Instead of vague statements like this one, let us be very precise. 

The TSP (Time-Stamping Protocol) document is not a document that 
"this WG is currently pushing". It is a document published by the IETF 
as a Proposed Standard, i.e. RFC 3161.

You did not answered to the specific question posted by Russ:
" What individual contribution was posted?  Can you give the URL to the 
message in the working group archive that requests that the working group 
consider it?  Did it result in a discussion?"

As far as I know, two years and a half ago, you made a submission to 
the PKIX WG. The header of that document was the following:

PKIX Working Group                                     Michael E. McNeil
Internet Draft                                         GMT
Document: <draft-pkix-bert-00.txt>                     Todd S. Glassey
Category: Informational                                GMT
Expires in six months: 17 November 1999                17 May 1999

                       Basic Event Representation Token
                           <draft-pkix-bert-00.txt>

This document has been presented at the Chicago meeting and when the chairs
(Tim was not chair at that time) asked how many people were interested in
this proposal, only two hands showed up. This support was insufficient
to progress the document in the PKIX working group. As you have been told,
you could (and still can) ask for a BOF and then progress this topic in a
new WG (if there is sufficient interest shown up in that BOF).

If you still fell that your case needs attention, please ask for a BOF,
and/or
attend the SAAG in Salt Lake City or/and send an e-mail to the Security Area
Directors, but in any case, leave the bandwith of the PKIX mailing list for
more useful discussions.

The only reply I am expecting from you is an acknowledgement that until the
next IETF meeting this topic is closed.

Regards,

Denis

---

From: "todd glassey" <[email-masked]>
Date: Fri, 23 Nov 2001 08:43:57 -0800

My apologies to all - I have to run for a couple of days so I will not be to
spend the time to craft my responses to the last couple of retorts to the
proposals I have made.

Oh - But I do intend to respond  - Just give me a day or so.

Todd
----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; "Tim Polk" <[email-masked]>; "Stephen Kent"
<[email-masked]>
Sent: Thursday, November 22, 2001 7:40 AM
Subject: Re: Motions before the WG

---

From: Tim Polk <[email-masked]>
Date: Mon, 26 Nov 2001 11:08:55 -0500

Todd,

>Oh - But I do intend to respond  - Just give me a day or so.

Please don't bother.  There is no point continuing this thread, since there 
is clear consensus on the list.  You are the only one who believes the PKIX 
WG should be compelled to accept every "properly formatted draft".  You are 
the only one who believes the PKIX WG should accept and promote a document 
that the vast majority of WG participants do not support, based on the 
marketing needs of the submitter.

I understand that the failure of BERT to progress within PKIX cost you 
funding.  However, that is *not* the fault of the group or the chairs.  It 
was your responsibility to build consensus within the group.  You were 
permitted to present the draft in the PKIX group at the Oslo meeting, 
weren't you?  You were unable to build support within the WG for this 
specification, so it did not progress in PKIX.  That is the way the process 
works.

If you wish to pursue this further, I strongly suggest you take this matter 
up with the two Security Area Directors.  (The ADs are Jeff Schiller and 
Marcus Leech; I have cc'ed them on this message, so you won't need to look 
up their email addresses.)  IETF Working Group chairs serve at the pleasure 
of the ADs.  If you can convince them that Steve and I are the problem, 
they have the power to rectify the situation.  If you can convince them 
that the IETF process is hopelessly flawed, they are in a much better 
position to influence the IESG to make the appropriate changes.

Now, I would like to see the group get back to the important work at 
hand.  We have some very important documents in front of the group, 
especially the DPD/DPV requirements and specification drafts.  Let's get 
the discussion back to the technical content this group is chartered to 
deliver.

Thanks,

Tim Polk

---

From: Tim Polk <[email-masked]>
Date: Mon, 26 Nov 2001 11:08:55 -0500

Todd,

Thanks,

Tim Polk

---

From: "todd glassey" <[email-masked]>
Date: Mon, 26 Nov 2001 12:32:54 -0800

Jeff and Marcus - What I have proposed is that the Charter of PKIX be
amended since there are major differences in how it is operated and what it
produces relative to your other groups. Also the opening paragraph of the
Charter is more of a road-map of historical accomplishments and really says
nothing about what the group is to be doing or how it operates.

As to this effort -  I have gotten some specific negative feedback from a
few of the "louder voices" on the list that this is not good. The problem is
that they all have Drafts and RFC's that would be effected by this
requirement which brings up and issue of propriety.

Further I wanted to submit a motion to curtail the breadth of the WG's
Chair's powers and require that PKIX, because it deals with protocols
specific to commerce, authentication and security applications that it like
other IETF WGs accept any number of protocols for standardization, and not
make any specific or unspoken requirement that there be only one protocol of
each type.

The motions are below in the text. They have nothing to do with BERT.

Oddly enough I have received numerous messages from people that have much to
lose if the WG turned against them, but they have applauded my commentary
and direction which tells me what I am doing here is right.

---

Tim - I heard you loud and clear as the WG Chair formally closing down this
line of conversation on this list - and will make this the closing remark
and transfer this to the IESG's mailing list. I have no intention of letting
this drop and intend to see these reforms brought into  PKIX or the public's
and other Standards Org's perception of the IETF adjusted accordingly.

----- Original Message -----
From: "Tim Polk" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Marcus Leech" <[email-masked]>; "Stephen
Kent" <[email-masked]>
Sent: Monday, November 26, 2001 8:08 AM
Subject: Re: Motions before the WG

> WG should be compelled to accept every "properly formatted draft".

Tim, the people that said 'no' are predominently the people that cannot, or
refuse to, give any good real world descriptions on how to use their
protocols, so I take offense to this comment of yours. The Archive will bear
me out. Further it is inappropriate for you to be taking the stance you are
here.

But for the record I have to ask - what is the problem with adding a
requirement that becuase of the application-centricity of PKI that its
"standards" require a statement of how to use them or what their scope is? I
want a specific answer here, not just one that says "it will slow the
process down too much"

> You are

What document are you talking about?  BERT? get a clue bro - what has BERT
to do with the need to "define what it is that a PKI protocol is used for
and how to use it?" -- and the BERT Draft would also require one of these.

And for the record - what I said is "that it is unreasonable for you alone
as WG Chairs' to make a determination as to what will and wont get worked
on.".

> funding.  However, that is *not* the fault of the group or the chairs.

No again -  BERT had nothing to do with it - Bert is just a Data Blob to
represent events in time and space. It also needed a use model.

> It
> weren't you?

Again What defines consensus - YOU DO - and that is what is broken.

> You were unable to build support within the WG for this

Again  - What have the issues before the WG have to do with BERT? It seems
that you folks are really threatened by the concept of being accountable.

And for the last time - what this effort has to do with is adding
accountability to your role within the PKIX WG . And the only people that
are pushing back on that is you.

So what was it exactly that I asking for? Several things as Changes to the
Charter listed below:

    1)    Eliminating the WG Chair's ability to run OpenLoop by defining
their specific functions instead of  the wide-open "Wide latitude" statment
that they are now constrained by . This is to effect PKIX only and may also
be submitted as a proposed amenedment to 2026 for general use, but PKIX will
still be constrained by it.

Part of this process will mean putting  in-place a method of advancing a
Draft to RFC that was purely mechanical, as would be the next step. This
means that any drafts submitted get advanced. (BTW - I see this as a key
component in maintaining control over what other groups adopt from us and do
not - and as such it also has to do with maintaining value in the Standard's
process). The IESG may push back on this and demand that it go through a
formal POISSON but I'll address that with them in a separate forum.

    2)    To add a requirement that a  statement from submitters as to what
their protocol is to be used for or is use requirements is now mandatory for
any draft or RFC being escalated to the next step. We donw need a users
guide but something that is more than just a External Reference
Specification would be nice.

    3)    Reinforcing that the role of the PKIX WG Chair is that of a Mentor
or Facilitator and not Judge and Jury. To do this the role and function of
the PKIX WG Chairs needs to be extended from what is submitted in the IETF's
WG Charter Specifications (2026 and follow on documents). This should be
accomplished by a section in each WG's Charter.

    4)    That the Charters opening paragraph be transfered to the "History
Section" since that is what it is. That a real Charter be put in place that
constrains the fairness and open standards environment that the IETF is
founded on.

> of the ADs.

Marcus and Jeff - Consider this submitted to you for consideration.

> If you can convince them that Steve and I are the problem,
> they have the power to rectify the situation.

Tim - you are being obtuse here. I never said resign - I never said that you
and Steve are ***the*** problem. What I have said is that the Charter was
the problem and have said this from Day One of this posting.

You have tried in your responses to make this personal and have failed bro -
its not about BERT or anything like that. Its about propriety and the
potential appearance of impropriety in this, a global standards
organization. Its about bringing culpability and a realizble process to PKIX
and building more interoperability and communitcation into what PKIX
produces. Its also about insuring the value of what PKIX produces in this,
the Global Internet/Networking Standards Committees.

> If you can convince them

--- SNIP - Denis' original response ---

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Nov 2001 14:20:01 -0500

>flexible by integrating as many PKI standards as possible. Same old

Michael,

As for what constitutes PKIX compliance, I agree that there is 
ambiguity, if one phrases the question in that form.  RFC 2459 
defines what a compliant CA must support re certificate and CRL 
generation, and also states what a compliant client must support re 
processing of basic cert/CRL fields and extensions.  But, since there 
are other PKIX standards, a general phrase such as "PKIX compliant" 
is ambiguous.

We did fail, as a WG, in having two highly analogous cert request 
protocols, and we are trying to not fail in that fashion again. 
Other WGs have also failed in this regard, and we have had similar 
overlaps in protocol functionality across WG boundaries, which is a 
failure of the larger IETF (IESG) process.  These failures, much like 
the proliferation of OPTIONAL fields in our standards and in those of 
most other WGs, have been the price of an open standards process in 
which we try to accommodate diverse requirements in support of a wide 
range of business models (of the sort that Todd would like us to 
devote more time to defining prior to beginning standards 
development). Standards like PKIX, which are intended to support a 
wide range of applications, are, of necessity, more general than more 
narrowly scoped standards.  We can either spend tremendous amounts of 
time debating what are the appropriate uses of these standards, in 
hopes of narrowing the scope and maybe reducing complexity, or we can 
accommodate a more diverse set of perceived requirements and create 
standards that have more optional-to-use-but-mandatory-to-implement 
features.  Since experience suggests there is little reason to have 
confidence that we can gain consensus on narrower requirements, we 
have adopted the latter approach.

I'm sorry that you don't perceive any benefits of X.509 v3 vs. v1. I 
think you are in a very small minority in this regard.

Steve