[Secdispatch] draft-jordan-jws-ct

[Carsten Bormann <[e-mail]>]

I would have said the below on the microphone later today, but IOTOPS
has been moved on top of SECDISPATCH, so I need to make my point on
the list(s).

As many of you know, I don’t care much about the mechanism proposed,
but then I’m not here to protect your feet from shotgun wounds.

However, I am strongly opposed against labeling a proposed mechanism
in a way that is misleading about its main characteristics.
There is nothing, *absolutely nothing* "clear text" about extracting
data from a JSON data model level input with an unspecified extraction
mechanism(*), re-encoding and processing this into a (hopefully)
deterministic(**) signing input, and then signing that with JWS (which
at least is a standards-track specification).
The latter employs base64 encoding, so it is even less "clear-text"
than the essence described above would leave possible (RFC 7797, the
only thing that might be called "clear-text" here, is explicitly
excluded).

I have already made this point repeatedly to the authors; this has
been ignored.  I'm therefore not very optimistic about the future
veracity of claims about this effort.

I have no interest in attempting to block this effort, but I would ask
that we at least institute some language policing here.

Grüße, Carsten


(*) The infamous `Transforms` in XMLDsig was at least specified.

(**) Which, to increase the insult, requires a detour via UTF-16 input
to create the deterministic signing input, cleartext ** *** (to
paraphrase a well-known Apple executive).