On Oct 22, 2008, at 7:50 AM, Tim Polk wrote:
I will concede that most of the excitement about IBE and other Weil
Pairing based cryptography has been in the research community.
However, the technology has matured and products are slowly
emerging. (I am also loath to write off any technology that
attempts to address our enrollment and credentialing problems, even
though I see it as a simple re-ordering of the same process. That's
a philosophical rathole, though.) Publication as Informational RFCs
is worthwhile since these documents provide a basis for
interoperability *if* adoption of IBE technology picks up steam.
We already have multiple non-interoperable implementations of IBE-
based email (Voltage and Trend Micro) These RFCs *won't* address the
fundamental interoperability problem between Trend and Voltage,
since Trend is using the Sakai-Kasahara algorithm and Voltage uses
Boneh-Boeyen or Boneh-Franklin. However, if additional companies
wish to join the IBE-based email market, these RFCs are a proactive
step towards interoperability of future implementations.
One motivation for adopting the Identum technology was that encryption
is based upon the sender's ID, where tokens combine with recipient's
IDs provide a means for many recipients to decrypt a common message
body. This approach solves a difficult problem when complying with
HIPPA, GLBA, PCI DSS, UK Data Protection Act that want outbound
messages managed. S/MIME encryption interferes with an ability to
monitor one's outbound traffic, making compliance assurance
difficult. It is my understanding all of these solutions are
encumbered, but I am not a lawyer.
So while I don't strongly object to these as informational RFCs,
I do wonder why, if only one implementation is ever likely, we
need any RFC at all. Its not like these docs describe something
one couldn't easily figure out were there a need, given that
the (elegant but not especially useful) crypto has been around
for a while without finding any serious applications.
Tim Polk wrote:
> Okay, I fat fingered this one. The S/MIME WG actually forwarded
> with a recommendation that they be published as Informational. I
> intended to respect
> that consensus, but for one reason or another, they ended up in the
> Tracker marked
> for Standards track.
> It is clear that the WG got this one right, and I have changed the
> intended status on
> both documents to Informational.
> Tim Polk
Ietf mailing list
Ietf mailing list