Application SC report

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

Everybody is probably aware that the Application SC has not had
much activity in the last quarter of 2004.  I'd like to make up for
that by proposing this SC's goal for 2005 and determine if the TC is
agreeable.

The goal is outlined below:


The use of PKI in applications, has so far been limited to SSL/TLS,
for the most part.  There are some efforts underway (SAFE) indicating
that Digital Signatures for uses other than Client-Auth  will become
prevalent in the next year or two - although this is domain-specific
(Pharma) and not generalized.

However, regulatory requirements are exerting greater pressure on
companies to focus on encryption of data-at-rest (SB1386, GLBA)  more
than on data integrity or non-repudiation.  IPSec and TLS  focus on
protecting data-in-transit (and even then only when a session is
established) and don't address the data-at-rest issue.

In line with the results of the PKI Survey last year, and the goal
of trying to make PKI more ubiquitous within applications, I believe
the Application SC should attempt to identify existing  models - or
define one if it doesn't exist - that addresses both  problems (DIT &
DAR) with the use of PKI at the transaction level - where each  atomic
transaction can be either signed, encrypted, or signed and  encrypted -
(something that I think of as "Transaction-PKI") so that  data is
protected regardless of whether a secure session can be established
or not, and regardless of where its resting location may be.

A model such as this will help bring about better security within
applications and create standardized mechanisms for data protection
rather than customers having to deal with one-off implementations
that may not be portable.

Once such a model is identified, the Application SC should further
determine the  optimal mechanism for getting this promoted and in use
by developers  - papers, standards, toolkits, sample applications, etc.

I, thus, propose that the Application SC undertake the following for
2005  to start making PKI as ubiquitous in transactions as it is in
SSL/TLS:

1) Identify models that can serve Transaction-PKI; examples are
    S/MIME, TLS, DSS, etc. (need to come up with models that are
    both XML and non-XML based);
2) Determine if the model(s) are capable of serving the needs of
    Transaction-PKI;
3) Determine gaps and what it takes to cover those gaps;
4) Get resources to cover those gaps;
5) Start promoting the model;

Comments?  Suggestions?

Arshad Noor
StrongAuth, Inc.