I have a common scenario that I believe should be addressed within this
group. I'll refer to it as domain-to-point secure messaging and it looks
as follows:
A user A(_at_)ISP(_dot_)com wishes to communicate *securely* with a another user
B(_at_)Company(_dot_)com(_dot_) The user B(_at_)Company(_dot_)com doesn't have
a cert (or if he does
A(_at_)ISP(_dot_)com doesn't know it). I see this as a common case, when
companies
start migrating to PKI and:
(1) A(_at_)ISP(_dot_)com is actually a user A(_at_)Company(_dot_)com, who has
temporarily left
his corporate premises and has a public email account at an POP/IMAP
service provider. A wants to exchange email securely with colleagues at
the Company, but not all of them have certs.
(2) A(_at_)ISP(_dot_)com is an external user with no association with
Corporate.Com, but who wants to send important secure email to
B(_at_)Company(_dot_)com(_dot_) A(_at_)ISP(_dot_)com can't access the Company's
PKI.
To solve this, the Company can deploy a domain securiy service, sort of
S/MIME proxy with public cert associated with
Smime-proxy(_at_)Company(_dot_)com(_dot_)
The user A(_at_)ISP(_dot_)com (the point) could then send S/MIME to this proxy
(the
domain) with request to forward the email to the end user
B(_at_)Company(_dot_)com(_dot_)
If A also has a cert, then B can reply securely directly or via the
S/MIME proxy, provided that the proxy has access to the A's PKI
(Company.Com or ISP.com).
BTW, this scheme also allows users to store corporate email on
unstrusted public POP/IMAP services providers. It can also be used for
secure mailing lists and cert distribution.
My question to You folks is:
1. Is there enough interest out there to work towards a draft?
2. It seems that this falls within the DOMSEC draft, but the scenario
above is not explicitly addressed. Any opinion on this?
3. Anybody else done something similar?
------
Luis Barriga
Ericsson Research