Stephen,
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.
Thanks,
Tim
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.
Stephen.
Tim Polk wrote:
> Okay, I fat fingered this one. The S/MIME WG actually forwarded
these
> documents
> 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.
>
> Thanks,
>
> Tim Polk
>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf