On 16/06/16 00:11, Matt Palmer wrote:
<snip>
For my money, I think redaction should go from 6962-bis. To my knowledge,
the implementations of redaction are far less mature than the
implementations of the rest of the spec, the one major client-side
implementation of CT has made a policy decision not to support it, and
there's still a number of different proposals to make it less prone to
attack (hashed labels, et al). I believe that it would be straightforward
to retrofit it into the system with a separate RFC at a later time, when all
the kinks have been worked out, so there's no reason not to remove it now
and have those people who believe redaction is worth pursuing work on it
separately.
+1
For all of these reasons, I've been growing increasingly uncomfortable
with the thought of the redaction mechanism (as currently defined in
6962-bis section 4.2) going into the Standards Track RFC that 6962-bis
is destined to become.
I think we should remove it from 6962-bis, and then work on a
draft-trans-redaction I-D (with the aim of publishing it as an
Experimental RFC). If we take this approach, I'll volunteer to be a
document (co)author.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
