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


Help: OASIS Mailing Lists Help | MarkMail Help

pki-tc message

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

Subject: Topics to move PKI TC Forward

Dear PKI Participants,
I have collected the ideas over the past seven months and here they are. We
would like to form a group of people that have interest in expanding the
original PKI TC in some of these directions or others, please review and
reply at your convenience. If I have mischaracterized any individual point
of view pleas let me know, there are some great ideas here!

Let's start with:

The quote from Bill Burr (NIST):

"For resistance to man in the middle attack, the "only practical solution
today uses PKI [and hard tokens]",  (SMARTCARDS) 

Ref: "Electronic Authentication in the U.S. Federal Government" (Slide 22),
Bill Burr, Asia PKI Forum Tokyo, Feb 2005. 


1.) As a technical committee, what technology standards do we establish?
    given that PKIX establishes international technical standards for
    PKI, and W3C has established XMLSignature, XMLEncryption and XKMS
    as standards?  If we cannot answer this question, then we need to
    figure out what is our charter.

2.) The TC conducted a survey 2-3 years ago that highlighted why people
    were not using PKI.  Yet, many countries around the world, the US
    Federal Government, the cable/satellite industry, the DRM world all
    use PKI in one form or another.  What is the real reason that the
    general business applications/IT developers shun PKI?  

3.) Is there a benefit to reducing focus on non-repudiation (total mess)?
Internet banking does not use PKI, non-repudiation card has been overplayed.
What about legal liability if you deemphasize non-repudiation. 


4.) 	PKI has no monopoly on non-repudiation!  The real benefits are more
subtle, and require proponents to think clearly and differently about
lasting transaction authentication (i.e. 'signatures') versus fleeting
access control. 

5.)	With a poorly articulated value proposition, PKI remains vulnerable
to *perceived* disruptive technologies like biometrics.  Actually the
technology is not vulnerable but its mind share is terribly fragile.  I am
sure we have all wasted countless hours answering management questions about
whether the latest gizmo is going to supersede digital signatures.

6.) -- I think an expectation that businesses will start using PKI per se,
is like asking a bank to "use" ferromagnetic.  Complex technologies often
have to be deeply bundled, which is why I think it is useful to think in
terms of a digital certificate supply chain.  We might have to put more
distance between the wholesale issuers of keys & certificates and the
deployment of apps that use those 'raw materials' in convenient value-added
forms (like smartcards, cell phones, set-top boxes etc.) 

7.) I think the PKI TCs historic role of implementing the PKI Action Plan is
still a good way of focusing and avoiding overlap on technical standards
development with PKIX etc.  There is still much valuable work to do under
Action Plan issues like engaging with vendors, education, application
facilitation, show-casing and collaboration.  

8.) W3C is tackling some of the more technical issues. There is a perception
that it is too technical- on both implementation and software development
side. Vendors don't have full support in toolkit and implementers aren't
scoping properly. Sweet spot may be identifying the capability of products
that contain functionality, investigation, analysis of market. We need to
attract members and tailor our work products to attract more members. The
charter is extremely broad and can accommodate many initiatives but not
necessarily not to build a standard. There is a lot of infrastructure work
being done.

9.) PKI is difficult with awkward interfaces, but PKI in smart card, token
and produced digital Signatures is a tremendous benefit, if it is under the
covers. Anti spam, combating the man in the middle may have PKI

10.) Is this a perception issue? We need a better elevator pitch. We have to
show its importance as plumbing even if it is difficult it is the only
truly. Case studies of real problem and show how PKI can be used to solve
that problem. Farming, phishing, spam detection-Need more on ROI on PKI,
need to demonstrate that it truly is not impossible to implement. If we can
show that it serves the enterprise- need a strong driver in the org.

John Sabo:

11.). Anders raises a good point for discussion, especially with respect to
the U.S. Government personal identity verification initiative, which is
essentially intended for authentication for physical and logical systems.
The access control components and additional applications are not an
emphasis of the NIST FIPS-201 guidance.  Of course, the U.S. government is a
huge collection of agencies with thousands of stove-pipe systems, and a mix
of legacy and COTS applications.  Some believe that the PIV infrastructure
will provide a basis for moving into the application space (in a decade?),
given this environment, since it establishes a cross-government and
government-contractor authentication foundation.  

12).) One general area of possible focus - addressing how PKI be of use in
better risk management given today's networking risks, especially document
spoofing (phishing), social engineering attacks, and document/web
authenticity requirements?  

!3.) Personal Identification verification card as being dev by US Govt.

14.) John mentioned the Federal Information Processing Standard (FIPS) 201
program as a highly topical subject matter to explore for an external
interoperability demonstration. The group likes the idea of a workshop
and/or symposium-maybe NIST would co-sponsor with OASIS. (FIPS) 201 program
as a highly topical subject matter to explore for an external
interoperability demonstration. The group likes the idea of a workshop
and/or symposium-maybe NIST would co-sponsor with OASIS.

Paul Evans (BAH):

15.) to discuss how they might comply with PIV.  The interesting wrinkle is
that they are not a government agency but see a great deal of value in the
PIV approach.  They have had internal and external CA's in operation since
1999 for high assurance identity verification and are now looking to "kick
it up a notch."

16.) I think the US Government PIV initiative is propelling reconsideration
of PKI by large enterprises and communities of interest/trust. CertiPath
(the aviation industry bridge CA) and SAFE (pharma CA) are gaining traction
in their respective communities.  It may well be that the PKI "killer app"
is not an application at all but rather a central component of IA&A
processes.  Path processing issues notwithstanding, federation is getting
more attention everyday and PKI is viewed as essential plumbing - certainly
not the glamour-child that the industry marketed and hoped it would become.

17) The biggest hurdles for wider use in applications outside of IA&A remain
the absence of a universal, open source, cross-platform API(s) that only
need a glue-layer between the app and the API and another between the vendor
product and the API.  That way, application developers don't have to bet on
the best or most widely deployed vendor product. The other barriers include
cost (alleviated some by shared service providers), awful user-interfaces
and users' technical understanding requirements. PIV will kick start the
dated PKI infrastructures. Non-govt agencies looking at PIV, SAFE and

18.) Work with ETSI: Riccardo Genghini  who chairs ETSI's e-signature group
has come to learn about or work, because I see him at most APKIF 
 meetings.  He is keen to participate, and has in past asked   only for a
statement of what OASIS would expect him to do, 
 and how we would assist him with shared outputs of the work. 

   19.) This is a fascinating survey (ETSI).  However, it is very specific
to one
  particular use of certificates, digital signature, and is very 
  oriented to the technical aspects.  Our survey is a more business 
  oriented--trying to identify the value proposition and potential 
  stumbling blocks to adoption.  In many respects, the ETSI 
 survey would be easier to fill out since it is asking about specific
 usage aspects (RFCs, what the digital signatures are being used for,
 etc.) rather than trying to get feedback on 'experience'.   It might be 
 worthwhile seeing if we can work with them on some kind of follow-on survey
to cover
  some of the 'experience' questions.  What do you think?


20.)  There are references to PKI in a number of other OASIS standards, such
as SAML, but they are mostly generic and rudimentary at best.  Therefore, I
think it would be useful for us to raise PKI awareness in other OASIS areas
and ask for greater specificity in their reports and recommendations.
Engaging in dialogues with these other groups is the way to go.

21.)   Am I correct in believing that XKMS comes under the OASIS purview?
If so, I'd like to see us get a work group on building a profile or profiles
analogous to SAML profiles for implementation.

23.).      Finally, Chris and I think that if the PKI group could host an
interoperability workshop, or conference, or challenge that puts SPML, SAML,
PKI, etc. together to solve real business problems, it would be a very
powerful way of having many OASIS initiatives integrate and bootstrap each
other, providing tons of great visibility, too.
24.) SAML 2 does a better job of attribute management as married with PKI.
Attribute management seems to be the area in the future. We could create a
subcommittee of the current PKI TC to add SAML2 as it applies to PKI and
another that will address distinction between keys and PKI, as they are
mutually exclusive.
The group will explore this work also. Peter also spoke about the potential
to redefine a PKI within a certificate or CA root cert. that would allow a
service provider to 
move from authorization to certification without multiple transaction.

25.) Work related to inter-domain PKI space (bridges, PKI based Identity
federation to validate certificates, path discovery and path validation over
complex applications. 

<<attachment: winmail.dat>>

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