[Secdispatch] Comments on draft-jordan-jws-ct-04.txt

[Eric Rescorla <[e-mail]>]

I took a quick look at this document and I continue to have the same
concerns about the overall approach I had previously, namely that
having allegedly signed data available in the "clear" is not in fact a
feature because we want people to validate the signature before
accessing the data and the validation process can then emit the
validated signed data. For these reasons, I do not believe that this
should be published by the IETF. If you feel it is important to have
an RFC, I would suggest the Independent Stream.


With that said, a few other finer-grained comments below.


S 2.

   Note that this document is not on the IETF standards track.  However,
   a conformant implementation is supposed to adhere to the specified
   behavior for security and interoperability reasons.  This text uses
   BCP 14 to describe that necessary behavior.

Is the point here that you don't want a ST document or are you
merely acknowledging that it is not one?


S 3.1.2.
I understand why canonicalization is required if you want to move
around cleartext JSON (ignoring the wisdom of this), but IMO
you're doing this at the wrong layer. Rather than having the
signing/validation system do canonicalization, instead
require that your system pass JSON "unmodified". This leaves
the implementor with two choices:

- Actually have a clear path through the system
- Canonicalize at the beginning and the end (thus effectively
  undoing whatever damage was done)

You can then define the signature system as just operating on the
text as given without requiring it to depend on canonicalization.


S 3.1.4.
It's not a good design to mix the metadata for the signed
object with the object itself as you do in S 3.1.3. This
makes the problem of the user understanding what is authenticated
and what is not even more difficult (for instance, what if
you need a key identifier or some other thing that isn't the
signature?).

I get that you want to decorate existing structures, but for
the reasons above, I think that's bad and you should instead
nest them as JWS contemplates. If we must decorate, we
should instead have a single standardized key which holds
its own structure that contains all signature-related
data.