W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2002

Re: MIME Multipart security?

From: Dave Crocker <dcrocker@brandenburg.com>
Date: Fri, 8 Nov 2002 18:06:46 -0800
Message-ID: <9965989457.20021108180646@tribalwise.com>
To: Chris Newman <Chris.Newman@Sun.COM>
CC: Dave Crocker <dcrocker@brandenburg.com>, Paul Hoffman / IMC <phoffman@imc.org>, <discuss@apps.ietf.org>

Chris,

Friday, November 8, 2002, 11:03:51 AM, you wrote:
Chris>   I predict that any public-key scheme
Chris> which fails to present one of those two user interfaces as the default user 
Chris> interface in the majority of products will be a failure

plausible assessment.  worth looking for solutions that satisfy it.


Chris> Be aware that SASL does not solve the problem of "mandatory-to-implement
Chris> interoperable security that's better than unencrypted plaintext passwords".

and isn't THAT interesting, given what is being required for MIME-based
services?


Chris> I'm somewhat dubious of the value of Multipart MIME Security.

I should explain a bit better what I had in mind, because a) it certainly
does not magically solve the problem, and b) it does not create an ability
to negotiate.

What it could do, if we organized things properly, is to isolate the
different issues of constructing authentication or privacy "systems" with
MIME objects.  For example, different cert schemes could be used with
possibly different authentication mechanisms that used the same signing
algorithm.

Currently, s/mime and pgp are monoliths. The suggestion is to break things
down so that basic matters of packaging are not proprietary and basic
algorithms can be plugged in more easily.


Chris>   Because
Chris> object-security is most useful in an enviornment where negotiation is not 
Chris> an option, the number of useful fundamental mechanisms I can think of ends 
Chris> up in the 2-3 range rather than the 8-12 range.

I don't think we know the number, because we haven't gotten any traction on
basic deployment.  I do not, for example, believe that large-scale SASL use
is likely to have 12 different choices regularly negotiated.


Chris> While it would be entertaining to try a 4th attempt at application-level
Chris> object security (preferably this time with more input from application 
Chris> experts and less from security purists), I think the odds of succeeding 
Chris> have decreased significantly since the last 3 attempts.

possibly. that is why my thought is something that is more of an integration
and refinement of existing mechanisms, rather than creating anything
substantially different.

Chris>   If you really 
Chris> wanted to pursue this direction, here's what I think it would take to 
Chris> succeed:

interesting thought.


Chris> 1) Really good open-source implementations with free-for-commercial use 
Chris> license, at least one in C and one in Java.
Chris> 2) Transition strategy from existing PKI systems that works and is included 
Chris> in 1.
Chris> 3) A really good spec, that includes good discussion about user interface 
Chris> requirements and how to deploy the system into an untrained average user 
Chris> community (likely involving automatic fetching of generated private keys 
Chris> over the Internet using TLS and a username/password pair).
Chris> 4) A major vendor or consortium backing the effort with enough clout to get 
Chris> the attention of the trade rags.

Chris> Of these, 1 and 2 are just plain hard, 3 goes against IETF traditions 
Chris> enough that I think the IETF would be the wrong standards group to do this 
Chris> in, and 4 may be nearly impossible in the current business climate.

1. is a lot of work, but isn't risky.
2. is where the real innovation needs to take place
3. is not as foreign to the IETF as you suggest, as long as we are careful
about which UI aspects we consider.  Email addresses and domain names are UI
issues...
4. can't make it a gating requirement, but might pick it up along the way.

d/


d/
-- 
 Dave Crocker  <mailto:dcrocker@brandenburg.com>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850
Received on Friday, 8 November 2002 21:07:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 16 July 2018 13:05:40 UTC