I am currently working as a consultant to the Massachusetts Health Data
Consortium (www.mahealthdata.org) on a "new-ish" S/MIME Gateway standard
effort. The Consortium is working with the Open Group to develop a product
certification program for these gateways, initially so that healthcare
organizations in Massachusetts can confidently buy these gateways and rely
on their interoperability. Obviously the Consortium, the Open Group, the
customers, and the vendors all hope that the standard will spread beyond
Massachusetts and beyond healthcare.
Currently most of the leading vendors are involved in this effort, and we
are receiving technical input from none other than Blake Ramsdell, now of
Sendmail. This effort dates back to late 2000 when the Consortium initially
convened half a dozen vendors to get them to make their products
interoperate in a signing-only mode. That spec was eventually cast as a
profile of DomSec, and interoperability between five vendors was
demonstrated at a HealthKey conference in April 2001. A subsequent pilot
deployment involving the Commonwealth of MA and two healthcare organizations
exposed some remaining issues with the specs, but more with the products
themselves, and this led to the current effort for product certification.
In this round of specification development, signing is back in, but we've
abandoned DomSec and are casting things as a profile of S/MIME 3.1. All of
the vendors involved were comfortable with this decision.
We are happy to have more people become involved with this program, as we
feel that S/MIME gateways are a very powerful paradigm for B2B e-mail
security, and that as more industries become aware of the technology,
especially in the new regulatory environment (HIPAA, GLBA), it will find
widespread adoption.
We have been aware of the SEEMail effort in NZ, and, in fact, would welcome
their involvement.
If anyone wants to learn more about the product certification program, the
point of contact at Open Group is Mike Lambert
(m(_dot_)lambert(_at_)opengroup(_dot_)org).
You should also feel free to contact me.
If any of you are interested, the Open Group's Messaging Forum is holding
two sessions on e-mail security at their quarterly conference. The first
session is on secure e-mail in the public sector, which will primarily deal
with the new PKI requirements in the US DoD. The second session will focus
on e-mail security for healthcare. The conference is in San Diego, CA, Feb
2-6. Learn more at www.opengroup.org.
-ben-
Ben Littauer
1 Moon Hill Road
Lexington, MA 02421
781-862-8784
mobile: 781-223-0890
fax: 810-963-6163
littauer(_at_)blkk(_dot_)com
http://www.blkk.com
From: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz (Peter Gutmann)
Date: Wed, 21 Jan 2004 16:14:22 +1300
To: Craig(_dot_)McGregor(_at_)treasury(_dot_)govt(_dot_)nz,
ietf-smime(_at_)imc(_dot_)org
Subject: Re: Status of RFC3183: Domain Security Services using S/MIME
"Craig McGregor" <Craig(_dot_)McGregor(_at_)treasury(_dot_)govt(_dot_)nz>
writes:
Is anyone aware of any similar implementations of DOMSEC in other
'communities' that have similar paranoia/security requirements? I think there
was something similar used for Health care in parts of the US?
There are a number of independent reinventions of DOMSEC (or DOMSEC-type
mechanisms) by S/MIME gateway vendors around (is there any vendor of such a
product who hasn't done something similar somewhere? You more or less need to
do this at some point). It's one of these things where implementors have
quietly gone out and fixed the problem (unfortunately probably in mostly
incompatible ways) while the standardisation effort was mired in politics and
pie-throwing.
This may have created a somewhat unfortunate situation where vendors already
have their own solutions and aren't too interested in a push for a single
standard approach, and even if someone were to push for a standards-track
design, everyone would feel the need to push their own products' approach as
the One True Solution (currently it's relatively clean and simple because it
was done by one or two people with a single design in mind). It could get
really messy, ending up as either a one-size-misfits-all design-by-committee
mess or something that vendors ignore because it conflicts with their existing
in-house design that they've had deployed for years.
So is it something that needs a proper standards-track RFC: Yes, definitely.
Would creating one at this point be effective: In the short term probably not.
In the long term it would certainly be nice to have for future
implementations and future deployments.
Peter.