Re: [pki-tc] Application SC report

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

Thanks, Anders.  I just noticed that you yourself were going down
this path in late 2003 (from the PKIX mailing lists).  I know you're
not part of the Application SC; so hopefully, if the TC agrees to
get this off the ground, I can count on your active involvement in
solving this tough problem?

I believe late President John F. Kennedy paraphrased it best, when
he said "We do this not because it is easy, but because it is hard."

My sentiments, exactly!

Arshad :-)

Anders Rundgren wrote:
> Arshad,
> The outlined project is indeed very ambitious, I like it!
> 
> It is though worth noting that in spite of more than a decade of FPKI activity,
> very little have been published describing how the US Federal agencies intend to
> deal with these complex issues including data-in-transit.  That is, we are on
> virgin territory.
> 
> Being somewhat leaning toward hands-on approaches, I believe that some
> use-cases are needed as there is a chance/risk that different market segments
> have slightly different requirements.  I have earlier provided some information
> on a B2B purchasing use-case.
> 
> Anyway, this is a truly giant task.
> 
> thanx
> 
> Anders Rundgren
> PKI Architect etc.
> 
> ----- Original Message ----- 
> From: "Arshad Noor" <arshad.noor@strongauth.com>
> To: "PKI TC" <pki-tc@lists.oasis-open.org>
> Sent: Tuesday, January 18, 2005 00:03
> Subject: [pki-tc] Application SC report
> 
> 
> 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.
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.
>