Re: [pki-tc] Application SC report - August 2005

[Arshad Noor <arshad.noor@strongauth.com>]

Couldn't agree with you more, Paul.  The NIST concept is exactly
what makes the JCE concept work today - Sun standardized the API
for cryptography in Java, allowing any vendor to supply a JCE-
compliant implementation through a CSP module without affecting
the application.

The impasse I see in the current situation is that all PKI-related
standards extant today, are mostly around ASN.1 (which is not easy
even for an "old dog" like myself to understand); whereas all new
development that's happening in the application world is around XML.
It seems to me, that if we wan't to win the hearts of the new
developers, we have to rally around the XML standards for digital
signatures and encryption, even though it was standardized by
another standards body (W3C) - I still haven't got my head around
XKMS, so I'll hold off judgement until I do.

Fortunately, the Java Community Process has standardized on a
single Java API for digital signatuers in the XML world - JSR-105
which spits out XMLSignature-compliant objects/documents, with a
reference implementation available today.  JSR-106 will do the
same for XMLEncryption.  The Apache Foundation has a C++ library
for the same although it isn't a "standard" like the Java API.

If we, as a group, get behind this, it keeps us aligned with a
huge community of developers and negates some of the splintering
that occurred over the last decade.  While the ASN boat may have
sailed, its possible to get on the XML boat before the PKI
community is blamed (again) for a promising technology not
having taken root.

Arshad Noor
StrongAuth, Inc.


Evans Paul wrote:
>  
> <Warning, rant ahead!>
> 
> Arshad,
> 
> It's one of the big challenges to all standards bodies and not just
> limited to PKI.  It seems that standards bodies are a bit like IT O/S
> and Application product vendors - everybody creates differentiators that
> "add value". The result is, in the case of PKI, a lot of product vendors
> who won't incorporate certificate-based services into their product
> lines because the standards are, in their words, "immature."  
> 
> We're still faced with the dynamic that I encountered in the WEMA PKI
> Interoperability Challenge I co-chaired from 1997 through 2001.  Back
> then I stated that the PKI market would never breakout of its
> niche-status until everyone involved in the market saw fit to
> collaborate and implement an open set of standards that limited the
> large number of options to a set of proven interoperable configurations
> that simplify the development tasks associated with certificate-based
> services that don't dictate which PKI vendor wins above all others.  
> 
> I always liked the NIST concept of a universal, High-Level Crypto API
> that would perform the essential crypto-functions that PKI vendors could
> write a glue-layer on one side of the API and product vendors write a
> glue layer for the other side.  
> 
> It would have been a great win-win situation in my opinion. Product
> vendors and systems developers would only have to write one (simpler)
> interface instead of guessing which PKI vendors might prevail in the
> marketplace (admittedly, there are fewer PKI product vendors today, but
> there is still more than one which at least double their development
> costs). PKI vendors would likely have a smaller share of a vastly larger
> market, thus increasing their overall revenues.
> 
> Look at the history of the messaging market.  Once SMTP became the
> universal protocol, the market expanded nearly at the speed of light.
> Ironically, secure messaging hasn't done so well - but that's more from
> the impact of the fragmented PKI market than anything else.
> 
> Rant off
> 
> Paul (who's stating only personal opinion here) Evans
> 
>  
> -----Original Message-----
> From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> Sent: Monday, August 15, 2005 1:26 PM
> To: PKI TC
> Subject: [pki-tc] Application SC report - August 2005
> 
> It appears that the more research I do into the possibility of digitally
> signing and encrypting transactions from the browser directly, the more
> complex the picture becomes - some technically, but more so from the
> number of groups addressing issues around this problem, but not this
> problem itself.
> 
> I recently became aware of an ad-hoc working group called the Web
> Hypertext Application Technology Working Group (WHATWG)
> (http://www.whatwg.org/) that is attempting to define standards around
> Web Forms 2.0 - a supposedly, better way to write web applications.  It
> is being promoted by the Mozilla Foundation and Opera, and they've
> submitted (or are in the process of
> submitting) their initial draft to the W3C.
> 
> I am attempting to determine the details of their specification and to
> see if they're addressed forms signing/encryption within their draft,
> thus adding one more detour before the real work can be done.
> 
> It does seem that PKI is gaining momentum - although in small
> steps:
> 
>    i) OpenOffice has implemented XMLSignature-based digital
>       signatures in their free 1.9x implementation of office
>       suites.  It actually works;
> 
>   ii) Sun has released a JSR-105 (XMLSignature)-compliant
>       reference implementation of the open-source Java library
>       so that applications can use a standard API to use digital
>       signatures (haven't tested it yet);
> 
> iii) The Java library compliant to XMLEncryption standards
>       (JSR-106) public-review is imminent, according to the
>       JSR-106 chairman; they're anticipating standardization
>       sometime this year, perhaps;
> 
> While enabling technologies are slowly coming to market, the ability for
> corporate IT developers to use this technology easily (as well as the
> technical documentation to make sense of it all) remains out of reach.
> We need to address this.
> 
> Arshad Noor
> OASIS PKITC Member
> Chairperson, Applications Guidelines SC
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>