MIME Multipart security?

Chris,


Thursday, November 7, 2002, 12:27:04 PM, you wrote:
Chris> That said, I happen to think both PGP and S/MIME are currently failures.

In formulating the I-D, I started wondering about ways to actually fix
the situation. It might be worth a few rounds of list discussion,
separate from discussion of the policy issue.  So, here's a new
thread...

Chris> My speculation of why both PGP and S/MIME are failures in the larger market 
Chris> is that the concept of client certificates is simply too complex or 
Chris> cumbersome for the average end-user absent a deployed global smart-card 
Chris> standard.

I suspect that this is a major factor.


Chris>   But it could also be because the standards haven't placed 
Chris> sufficient requirements on user interfaces and the bootstrap problem or 
Chris> that the products to date haven't focused enough on usability to be 
Chris> actually usable by the average end-user.

The UI problem is difficult.  And certainly the products I have seen
are not easy enough to use.  I'm not sure there is much the IETF can
do about that, though, unless we can devise a cert scheme that
naturally creates an easy user scenario.

Offhand, I'd suggest that both email and the web have in fact done
just that. The basic model for each of them is wonderfully simple. Can
we say the same for PGP or S/MIME?  Or at least for an acceptable cert
mechanism?


Chris>  Personally, I think the
Chris> answer is that whenever the IETF produces a hop-to-hop protocol we mandate 
Chris> the use of a hop-to-hop layer which provides a deployable security 
Chris> mechanism such as TLS with plaintext passwords, or an SSH-style 
Chris> Diffie-Hellman exchange.  In theory, it doesn't provide as good security as 
Chris> S/MIME or PGP/MIME, but in practice it provides better security because it 
Chris> will deploy and be used in the larger market.

Very creative and interesting idea.

A different thought occurred to me:

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.

But SASL is not just a negotiation framework.  It is a common
representation framework.  Would it help to have that for MIME?

Oh.  We do.  That's what Multipart MIME Security was intended to be.
The problem is that it isn't used much or at all by the two standards.

However it could be.  The interesting differences between the two
standards is not in their packaging.  And, in fact, one could strongly
argue that the underlying algorithms ought to be shared.  And for
authentication the user data is clear-text anyhow.  So it's just fine
to isolate the security stuff into a separate MIME part.

Well, that's true for encryption, too.  The user data encryption is
not the interesting part.  The interesting part is the public-key
control stuff.

There is no reason they cannot share mechanisms for data encryption
and still have loads of product differentiation in the control
mechanisms.

So that's one thought.

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.

Also my guess is that S/MIME certs require too much infrastructure and
PGP requires too little.

It would be interesting to explore this.

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 01:50:57 UTC