Anders Rundgren wrote:
The following is related to the S/MIME discussions.
...
If we (security experts) want to create anything that could match closed
networks such as Skype, having 100M+ users enjoying full
end-2-end-security, I think we need to be a bit pragmatic and not hoping
that users should be extremely interested in certificates, or that the
UN should provide us with a universal root certificate.
I see this as an interesting question. There are pros and cons. First
con; why would we want to do that? Just use Skype. Or, Nelson talked
about AIM having some form of crypto. Also Jabber has something.
In contrast to that, one of the things that Mozilla Messaging should be
looking at is exactly that. The comparisons between email and chat are
strong if not perfect, and while old things like email aren't likely to
die any time soon (telegrams just got shutdown last year!), all new
interesting work is being done in the peer2peer domain.
So an obvious thing is to add chat to Tbird. How to do this? An
interesting question. However, this is a business-level requirement,
not a user-level or tech-level comment.
...
Each domain (host) have a "pseudo-CA" using a commercial-grade SSL
certificate as a CA certificate. Certificates created by such a CA
should have a specific DN format (in order to be valid), where the
host-name of course must be a core component (you can only certify
things in your own domain).
The problem I see here is that you are (all) starting from a tech pov.
Bottom up. What's the point of that? Granted, it will work in theory,
but the market has shown that successful things start from a top-down,
market focus, they win out in the end.
So, I would suggest defining what the chat system is that users of say
Tbird would want. (Or Firefox.) Then, once you've figured that out,
start meeting those requirements.
Alternatively, if you do want to take a tool -- "I have a cert" -- and
wish to thrust it down people's throats, then you are reducing your
chances to essentially lottery proportions. You have to be right about
things you aren't looking at and don't know exist, and users have no
difficulty in ditching tools that are too cumbersome.
Based on such a trust infrastructure, an on-line-based secure messaging
system should be able to achieve Skype-level scalability while still
being fully distributed. I haven't really gotten down to the
nitty-gritty with the messaging itself, because a system like
this obviously requires a bunch of other hot-shots as well :-)
So from this, I gather you want: scalability + distribution. Do you
want no center(s) at all?
Enrolment issues? Skype does this without the user having to know what
a certificate is.
I sense an easy enrolment process. OK, I agree with that.
Applications include all kinds of interactive communication with mobile
phones as a really interesting target unless it gets outlawed.
Mobile phones -> strange messaging formats like SMS. Avoid Internet
assumptions like TCP/IP, make it strictly messaging. Well, ok, any chat
system should have done that anyway. But this is getting too deep.
Do you want file-sharing? Do you want video? These are both common
with modern day chat, and they strain the architecture depending on what
choices you made. Do you want integration into other things? E.g., if
you ended up piggybacking on some p2p networks, you might end up with
file-sharing and backup possibilities.
Do you want to have:
no originated authentication (leave it to the users)
an upgrade path to third party auth (aka CAs)
third party auth form the start?
It depends on your user base I would guess. If we are talking ordinary
mom & pop, they are happy with whatever works immediately, so the first.
If we are talking corporates, sometimes they want authentication from
a third party, and sometimes they want it from a first party (themselves).
just some thoughts!
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
