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

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jul 2021 09:27:33 -0700

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Jul 2021 21:05:26 -0400

> feature because we want people to validate the signature before

While I agree with you that this is the right thing for data in transit,
I think that you are presupposing a particular use case.

For instance, some systems have a need to provide for a third-party witness for data.
The transfer between producer and consumer may itself be "secure".
The witness signature has to be detached; it might not even ever enter the
systems of the first and second party.

But, I agree with what you said at the mic, that either make the transport
not screw with the content, or make it the application's problem.

As I understood Carsten's suggestion, we should canonicalize the data by
turning it into CBOR, and using COSE.

    > text as given without requiring it to depend on canonicalization.

I think that the problem that they have is that they don't actually keep the
text.  Someone decided it was too expensive.  They put it into some database.

I agree that it's probably not wise, and it creates a very poor audit trail.
I don't feel as strongly as you about ISE.  I don't know what I think.
Mostly, I'd rather that there were inside the tent...
(OTH, I've complained about too many WGs)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jul 2021 03:23:05 +0200

> turning it into CBOR, and using COSE.

Actually, when I started saying that, I meant it as a reduction ad absurdum.

But after thinking about it, it is actually not so absurd, but the best way to handle the use case — everything is already in place for that.

But that simple change is just a different function to compute a signing input from data at rest — the more difficult question is what is it that you compute the signing input of, and the fact that you now have a signature for something that is in a complex and not entirely well-defined relationship to the data that is in your database and that you might think some subset of which you maybe have a signature for.

If your application design can take care of that part, then you win (and can use CBOR-deterministic + COSE, or if you must, translate to XML first and do an XMLDsig, etc.).

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 27 Jul 2021 09:41:28 +0200

Unlike JSON which nowadays [1] have a working deterministic representation [2], CBOR leaves a good portion of this crucial part to application developers to figure out.
The net result is a fragmented CBOR space with groups like FIDO creating their own unique definition called CTAP2.

The authors will consider the ISE path for the proposed work-item.

thanx,
Anders

1] Encountered floating point parsing and serialization issues have been fixed by the platform vendors which makes the task creating an RFC 8785-compatible canonicalizer quite simple.
2] By constraining the Number type to IEEE 754 double and requiring the String type to be immutable.

On 2021-07-27 3:23, Carsten Bormann wrote:
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jul 2021 12:58:03 +0200

> The net result is a fragmented CBOR space with groups like FIDO creating their own unique definition called CTAP2.

Statements like this are a reason why I’m calling for some supervision here.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 27 Jul 2021 17:08:00 +0200

> Statements like this are a reason why I’m calling for some supervision here.

Another action could be to consider co-creating(!) an "I-CBOR" profile that would not only address documented CBOR interoperability issues for normal data exchange [1], but also make CBOR usable in cryptographic contexts without necessary embedding data-to-signed in bstr like COSE.

thanx,
Anders

1] https://github.com/w3c/webauthn/issues/1624#issuecomment-862672788

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jul 2021 17:41:59 +0200

> Another action could be to consider co-creating(!) an "I-CBOR" profile that would not only address documented CBOR interoperability issues for normal data exchange [1], but also make CBOR usable in…

[Not in citation given.]

[1] discusses a case where, in two unimplemented extensions, application developers wanted to ship floating point values in the specific format they happen to have them.  That would have been fine, but it means there would have been a deviation from 4.2.1.  4.2.1 *is* the interoperable set of deterministic encoding rules; deviations are explicitly allowed, but indeed mean a deviation.

And then there is the old “canonical” encoding from 7049 that is described in 4.2.3 of 8949.  We are genuinely sorry about that, that was a design that got sufficient negative feedback from implementers over the years that we decided to upgrade it by providing a preferred deterministic serialization as well.  So I currently have exactly two implementations: cbor-canonical, which implements 7049’s old “canonical" serialization, and cbor-deterministic, which implements 8949’s deterministic serialization.  They are 44 lines each (and don’t differ much, obviously).  In my case, I can’t even implement “in the specific format I happen to have”, because I don’t have floating point values in specific formats; if this is ever needed, this could be supported by adding new application types for these formats, of course.

Grüße, Carsten