OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pki-issues message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: More comments on PKI Action Plan


At the end of this message are some comments on the
PKI Action Plan that I didn't see in John's email
from yesterday.

John, is the next step that each of the volunteers from
yesterday's call finds the comments that pertain to our
sections, assigns a tracking number for each comment and
develops a recommendation, then sends the recommendation
and tracking number to the list? Or maybe to you, so
you can integrate it into your Word document?

I just want to be sure I understand the process.

Thanks,

Steve

-------- Original Message --------
Subject: [pki-issues] EEMA Comments on Action Plan
Date: Tue, 21 Oct 2003 10:26:04 +0100
From: "Jeremy Hilton" <jhilton@viviale.com>
To: <pki-issues@lists.oasis-open.org>

Thanks for sending these on, Jeremy. Do you have
permission to forward them on to others? If so,
please send them to pki-issues@lists.oasis-open.org.
Thanks,
Steve
> Jeremy Hilton wrote:
> 
> Hi Steve,
> 
> Herewith some initial comments on the Action Plan:
> 
> ECAF 1> Jeremy, I think the most relevant question (again) is what
> budget OASIS have to implement this action plan (which fortunately can 
> be called realistic rather than over-ambitious). That is where the PKI 
> Forum had most problems with, even though in those days they must have 
> had sufficient budgets - I fear they may not nowadays.. Especially 
> action item 2 (PKI interoperability testing, cfr. our pkiC) is known 
> to cost quite a bit, just to get people focused and hence get things 
> moving. I also hope, and we should urge them, that they will not 
> duplicate pkiC, but rather build on it, that's also what we did when 
> we embarked on pkiC early 2001: we used whatever was available and 
> useful coming from the PKI Forum.
> 
> ECAF 2> Jeremy, I fully support <ECAF 1's> comments. I would add that
> as well as pkiC, the OASIS activity should also take into 
> consideration the recent interoperability work undertaken in Japan.
> 
> I particularly support the concept of application guidelines/standards
> "cookbooks".. anything that OASIS can do to overcome the 
> real/potential interoperability issues for vendors and user 
> organisations should be welcomed. Providing some assurance that the 
> products from vendor "x" will work with products from vendors "y" and 
> "z" would be very very helpful in this increasingly "joined-up" world 
> of ours.
> 
> I will forward more as they arrive.
> 
> TTFN
> 
> Jeremy
> 
> Jeremy Hilton
> +44 7753 816596

-------- Original Message --------
Subject: Notes from PKI Labs/PKI Workshop Concall
Date: Fri, 24 Oct 2003 17:36:04 -0400
From: Steve Hanna <steve.hanna@sun.com>
To: PKI TC Issues SC <pki-issues@lists.oasis-open.org>

Here are my notes from the PKI Labs/PKI Workshop
conference call on Monday, October 21.

* Krishna Sankar was especially enthusiastic about
  our work. He encouraged us to have a paper and a
  panel at the PKI Workshop. Krishna also asked me
  to send him the full list of obstacles that we
  brainstormed last spring while preparing the survey.
  I'll do so.

* For educational materials, focus on applications
  and scenarios. Not technology.

* What do the respondents mean by electronic commerce?
  I said we don't know. We may need to do some more work
  there.

* What do the respondents mean by document signing?
  I explained that we *did* get more details about that.
  Neal McBurnett said we should develop examples and
  scenarios. Then standards and tools (open source or not)
  can be developed from those.

* Neal McBurnett said Open Source software is very
  important for driving PKI adoption. A lot of projects
  start small as informal pilots. Without free software
  (CA software and document signing and email...), this
  can't happen and adoption is slowed.

* Krishna asked what research opportunities were uncovered
  by this survey. I said I don't know. I'll have to think
  about that.

So there's some more input for our discussions.

I hope we can meet soon! We have a lot of things to
talk about.

Thanks,

Steve

-------- Original Message --------
Subject: RE: [pki-tc] Proposed changes to PKI Action Plan comments
Date: Sun, 19 Oct 2003 19:00:00 -0700
From: "Pawluk, Jean" <jpawluk@inovant.com>
To: "'Steve Hanna'" <steve.hanna@sun.com>,PKI TC
<pki-tc@lists.oasis-open.org>

Steve and all,


Due to a prior commitment I will miss the majority of the call.

However, I would like to add the following comments that I wrote a
couple of years ago to t=
he
IETF PKIX group and I still have not seen a lot of improvement (unless
you call looking at=
 the many
vendors slowly sinking into oblivion a solution) from the users point of
view.

As I have often said, just as a airplane is a very complex bit of
machinery that somehow ge=
ts
 off the ground and can transport me from one location to another as a
passenger, we need t=
o make=20
security solutions such as PKI as easy to use from the passenger (user)
point of view. I d=
on't want to know=20
about the mechanism unless I am the mechanic or pilot, I just want to
pay my fare and to my d=
estination.

What are we doing to make those seamless yet secure applications a
reality ?  I think we a=
s industry
may have done too much work on practices yet very little on how to use
it easily. Why shoul=
d
anyone other than industry specialist be expected to know or care how
PKI works?  Its ti=
me to think
outside the PKI silo, so please keep up the good work to date with
survey with actions to i=
mprove everyone's
lot.

Regards
Jean

Sent: Monday, November 12, 2001 12:51 PM
To: ietf-pkix=40imc.org=20

Ah, so we are back to one of the original questions of everyday
transactions -=20
Who do I trust and just how much do I really trust them?

On an everyday basis, people everywhere apply some decision making
process
(with or without full awareness of the process) to every transaction
that
occurs between them. To take this a step further, business policy
applied to
computing systems often tries to make this sort of decision process and
apply it to applications.  PKI is one way that this trust binding is
attempted and it often fails quite miserably. Humans seem to do this
relatively effortlessly based on their experiences.

What's really wrong with PKI is that is it is difficult for most people
to
implement and costly to use and it just doesn't happen as quickly as
some
human judgment call on who they trust in any transaction.  Where is the
granularity of trust levels, the recognition that trust is temporal and
transitive presented in a fairly simple way for the everyday programmer
use?

We can now plaster the world with X509 certificates in various forms
that
work the way it was intended (and this has taken several years) but we
as a
group have done little to make it easy and relatively idiot proof to use
PKI
in applications (and there are many perfect idiots in our wide world).

I have looked into and tested many a CA vendor's toolkit and let me say
it
just isn't easy to use any of them. Where is the application enabling
middleware that is easy to use? (Yes, there are several other standards
groups addressing this is some piecemeal fashion and there are some
vendors
who are beginning to address this space.)

 I look at a lot of the work being done with PKI and XML in wonderment
of
really allowing the =22average=22  (read, less experienced) programmer
who will
follow some standard and then really botch things up, expose keys, etc
due
to lack of knowledge on how to do it securely.

Let's get real and do something about all this, that makes PKI an easy
and
reliable method of enabling trust on an everyday basis with all the
goodness
that PKI offers instead of making it so difficult that the average user
would rather get a root canal than use PKI.

Just my opinion,

	Jean Pawluk


PS As an architect and senior manager I am often astounded how many
firms do
not know their own business well enough to decide what needs to be
secured.

-------- Original Message --------
Subject: Proposed changes to PKI Action Plan
Date: Fri, 17 Oct 2003 16:58:51 -0400
From: Steve Hanna <steve.hanna@sun.com>
To: PKI TC <pki-tc@lists.oasis-open.org>

Here is a summary of changes to the PKI Action Plan
that have been suggested during the last few weeks
of confidential review. I have divided these proposed
changes into two categories:

1) those that I think may be controversial or that are
   especially substantive and should therefore be discussed
   in the PKI TC meeting on Monday

2) those that I don't think we need to discuss, since
   there is probably a consensus on them

Please bring this email to our Monday meeting so we
can discuss these changes. If you have received any
other suggestions for changes, please send them to
the PKI TC email list. Also let me know if you think
I have missed any changes sent to the PKI TC list.

I will note here again that I am concerned the PKI TC
will become overwhelmed by the volume of comments.
I expect this will be even more of a problem once we
open the document up for public review. I suggest again
that we consider creating an Action Plan editing committee
that would receive comments, evaluate them to decide
how they should be handled, and send periodic reports
to the PKI TC on what comments have been received and
how they have been handled. I will raise this as a
formal proposal at our meeting on Monday.

Thanks,

Steve

P.S. I'm a little concerned about copyright issues when
taking changes verbatim from someone's suggestion. Unless
we have explicit permission from an author to use their
wording in our Action Plan, I will reword things enough
to resolve copyright concerns. Sun Microsystems (my employer)
has agreed to donate copyright on my work on this document
to OASIS. And I'm going to considerable lengths to make
sure that I don't copy text from anywhere.

-------

Proposed Changes to be discussed:

[Removed changes 1-6 since they were discussed during
the October PKI TC concall]

7. From HEPKI-TAG:

* Prebaked PKI configurations have been tried and
  they weren't used. Like PKI Lite.
* The reason why they haven't been used is that it's
  so hard to get lightweight CA and application software.

8. From HEPKI-TAG:

* With web-based PKI, there's no way to force the
  user to reauthenticate. That's a problem if the
  user has walked away from their desk, leaving
  their smart card or soft token activated.

9. From HEPKI-TAG:

* Are you [the PKI TC] going to act before February?

10. From HEPKI-TAG:

* Applications should use the PKI support that's built
  into the operating system. Then they'll get smart card
  support automatically.

11. From a HEPKI-TAG Member:

> Too Much Focus on Technology, Not Enough on Need [highly ranked]

Instead of "more education for management and users" (which is like
saying "You're not smart enough!") I think what you're hearing is
level-headed folks pointing out that PKI is not magic pixie dust.  I
think the appropriate response to this one is to focus on applications
and specific requirements of significant user communities.

That's what you're starting to do in terms of the focus on application
guidelines for document signing, secure email and electronic commerce,
so that's good.

> Ask Application Vendors What They Need

In concert with the comment above, I think asking *user* communities
what they need is really important.  E.g. what do they want in terms
of that nebulous "electronic commerce"?  Does that really mean "I want
to make money so I'll go where the money is - commerce?", or does it
mean something else more helpful?

E.g. what aspects of "secure email" are they really looking for?
Absence of spam?  Confidentiality?  Authentication?  Might non-PKI
methods (e.g. opportunistic encryption of smtp and/or other changes to
the email infrastructure) be more feasible?

12. From a HEPKI-TAG Member:

And on document signing, for me the biggest issue is document formats
and providing some assurance that what you signed is what you saw.
Both of these are hard in the current environment.  The most popular
"document" formats are proprietary, complex and very susceptible to
making them look one way when signed and another way when validated.
This makes interoperability pretty hard.

An update on xml-signature would be nice.  But I'm personally still a
fan of plain text signed with S/MIME or PGP until something better
comes along.

13. From Anders Rundgren:

AFAIK web-based signing in spite of being a much needed
feature for on-line activties is not even a standards task.
Every bank, e-government have therefore to deploy their
own unique or purchased signature plugin.

14. From Anders Rundgren:

I seems that the standards used for on-line certification suffer
from a real-world disconnect as well as being non-standard.
Microsoft's Xenroll is a non-portable solution.  I'm
puzzled that nobody digs into this as on-line certification
schemes are the only thing that scales.  The real-world
disconnect is that in all *real* certification schemes for
individuals the *provider* wants to control every parameter
it can.  BTW, if somebody is interested in this area I'm
interested in doing something here!

15. From Anders Rundgren:

AFAIK none of the major leading or obscure vendors
of PKI-enabled cards have donated support to Windows.

16. From FPKITWG:

In further discussion of costs, ROI was mentioned by some as
the real key to addressing costs. Others, including Michele
Rubenstein, expressed the view that someone needs to come up
with documentation on the total cost of ownership for PKI, not
just ROI. She mentioned some related work that the Directory
Forum in the Open Group is pursuing for directory. 

17. From FPKITWG:

The only real discussion of the action plan was around testing.
The PKITS and NIST Protection Profiles are familiar to this
group and will address interop issued that relate to conformance
(as well as a common set of functions for all clients). However
for non-path-validation topics there was some interest in the
Open Group taking up a role for other testing. Note that there
were some Open Group folks in the room and it was they who
expressed this interest.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]