Re: Mandatory MIME security

Chris Newman wrote:
> 
> My speculation of why both PGP and S/MIME are failures in the larger 
> market is that the concept of client certificates is simply too complex 
> or cumbersome for the average end-user absent a deployed global 
> smart-card standard.  But it could also be because the standards haven't 
> placed sufficient requirements on user interfaces and the bootstrap 
> problem or that the products to date haven't focused enough on usability 
> to be actually usable by the average end-user.

Others that I know who have done informal surveys of "average" computer 
users also state that the complexity of client certificates is the 
reason for low adoption.  Personally, I don't think it is that big of an 
issue.  My own informal survey of "average" computer users didn't even 
get that far:  they either didn't see a need or didn't feel they had a need.

> So where does that leave us?  If the IETF produces a hop-to-hop protocol 
> which can transport non-public data and wants it to be technically 
> competent, we must require some sort of interoperable security that's 
> better than unencrypted plain text passwords.  But the two standards 
> track protocols we have for object security are currently failures and I 
> agree with Dave that they are unreasonable to mandate.  Personally, I 
> think the answer is that whenever the IETF produces a hop-to-hop 
> protocol we mandate the use of a hop-to-hop layer which provides a 
> deployable security mechanism such as TLS with plaintext passwords, or 
> an SSH-style Diffie-Hellman exchange.  In theory, it doesn't provide as 
> good security as S/MIME or PGP/MIME, but in practice it provides better 
> security because it will deploy and be used in the larger market.

Pardon the ignorance, but is there a deployed hop-to-hop protocol using 
something like TLS?

-andy