Re: MIME Multipart security?

A
>The problem is that the majority market is not willing to compromise much 
>in the way of usability in order to attain security (and rightly so, 
>IMHO). And there are only two security user interfaces that have proven to 
>be widely deployable: username/password entry forms and smart cards that 
>"just work" like house keys or car keys.  I predict that any public-key 
>scheme which fails to present one of those two user interfaces as the 
>default user interface in the majority of products will be a failure in 
>the general market.
>
>>SASL is popular.  Would that we could have such a security negotiation
>>framework for store-and-forward object security.  Alas, trying to
>>"negotiate" in store and forward is rather difficult, as the
>>email-based use of CONNEG is demonstrating.

OK .. so IMHO the problem is still how do you make opportunistic key 
management usable across domain boundaries.

CONNEG is a possible way to solve the problem but NAPTR records could do 
the trick as well.



>>But
>
>>The other is to revive the simple PKI effort, to get a basic mechanism
>>that supports only a core set of cert functionality -- rather than the
>>cornucopia of policies that have been pursued -- and that scales but
>>is real, real easy to use.

yes please ...


>A major problem is that the customers who pay real money for 
>top-of-the-line object security have already choosen S/MIME and have 
>little interest in any alternative.  That leaves most large companies with 
>no will to expend resources on the larger problem of deployable object 
>security.
>
>While it would be entertaining to try a 4th attempt at application-level 
>object security (preferably this time with more input from application 
>experts and less from security purists), I think the odds of succeeding 
>have decreased significantly since the last 3 attempts.  If you really 
>wanted to pursue this direction, here's what I think it would take to succeed:
>1) Really good open-source implementations with free-for-commercial use 
>license, at least one in C and one in Java.
>2) Transition strategy from existing PKI systems that works and is 
>included in 1.
>3) A really good spec, that includes good discussion about user interface 
>requirements and how to deploy the system into an untrained average user 
>community (likely involving automatic fetching of generated private keys 
>over the Internet using TLS and a username/password pair).
>4) A major vendor or consortium backing the effort with enough clout to 
>get the attention of the trade rags.

NO ... a standard methodology to find the keys..and the willingness of the 
Security AD's to confront the issue head on ..

I posted a earlier message on the key management issue which may have been 
lost in the shuffle the ID I posted directly dealt with these issues.

Title           : Use of the DDDS System for Cryptographic Key Discovery
                           and Retrieval

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shockey-ddds-pki-00.txt

Its raw but lays out the basics.

The old siked list is still active and I personally interested in a BAR BOF 
on these issues.. if interested ..please post your interest.








 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:richard@shockey.us> or <mailto:richard.shockey@neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Received on Sunday, 10 November 2002 18:56:29 UTC