RE: [pki-tc] Application SC report

["Sabo, John T" <John.T.Sabo@ca.com>]

Arshad,

This is an interesting proposal and worth pursuing.  The question has
applicability in privacy regimes, where there are requirements for
carefully controlling disclosure of personal information to authorized
parties, where simply providing confidentiality in SSL/TLS sessions is
not an adequate solution.


John


------------------------------------------------------------------
John T. Sabo, CISSP
Manager, Security Privacy and Trust Initiatives
Computer Associates International
2291 Wood Oak Drive
Herndon, Virginia, 20171
USA
Phone: +1 703-708-3037
Mobile: +1 443-629-6198
------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and
may contain confidential and/or privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.



-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
Sent: Tuesday, January 18, 2005 6:53 PM
To: PKI TC
Subject: Re: [pki-tc] Application SC report

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_workgr
oup.php.
> 


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_workgr
oup.php.