Hi Russ,
Also inline, trimming some...
On Wed, Aug 17, 2022 at 01:54:23PM -0400, Russ Housley wrote:
> >
> >> I suggest that we add the following:
> >>
> >> With the publication of this document, implementers are encouraged to
> >> migrate used of the previous countersignature algorithm to the one
> >> specified in this document. In particular, uses of
> >> "CounterSignature" will migrate to "CounterSignatureV2", and uses of
> >> "CounterSignature0" will migrate to "CounterSignature0V2". Of
> >> course, the validation of "CounterSignature" and "CounterSignature0"
> >> might be supported to handle previously generated counter signatures.
> >
> > The general sense of this looks good to me.
> > For transparency, RFC-to-be 9052 appears to have all needed approvals
> > (including Paul's as AD), and says this (in the context of "crit"):
> >
> > Additionally, the header parameter "counter signature" (label 7) defined
> > by [RFC8152] must be understood by new implementations, to remain
> > compatible with senders that adhere to that document and assume all
> > implementations will understand it.
> >
> > with lowercase "must". So I think the text in this document would better
> > align with 9052 if we s/might be supported/must be supported/.
>
> I suggest:
Looks good modulo nits.
> With the publication of this document, implementers are encouraged to
> migrate used of the previous countersignature algorithm to the one
> specified in this document. In particular, uses of
> "CounterSignature" will migrate to "CounterSignatureV2", and uses of
> "CounterSignature0" will migrate to "CounterSignature0V2". In
> additional, verification of "CounterSignature" must be supported by
s/additional/addition/
> new implementations to remain compatible with senders that adhere to
> [RFC8152], which assumes that all implementations will understand
> "CounterSignature" as heading label 7. Likewise, verification of
s/heading/header parameter/
> "CounterSignature0" may be supported for further compatibility.
>
>
> >>
> >>> In particular, the current state of affairs gives the COSE header parameter
> >>> with label 7 ("counter signature") privileged treatment in that senders are
> >>> free to assume that recipients can understand and process it, even if it is
> >>> not listed in the "crit" header's value. While a reasonable reader might
> >>> assume that being marked as "deprecated" directs a sender to not omit the
> >>> parameter (though more concrete guidance on that point seems apropos to
> >>> me), I do not think that there is a clear implication about whether an
> >>> impelementation must continue to implement support for processing this
> >>> header parameter. In order to ensure a smooth deprecation process, I think
> >>> this document needs to make a specific statement about whether the
> >>> requirement on implementations to understand this parameter remains.
> >>> (I am currently grappling with how to describe this situation for RFC-to-be
> >>> 9052, that does not discuss "counter signature" but does retain RFC 8152's
> >>> guidance that labels 0-7 SHOULD be omitted from the "crit" value. I
> >>> believe that the requirement on implementations to understand and be able
> >>> to process "counter signature" must remain for the purposes of RFC 9052.)
> >>
> >> We could also warn that over time implementations are expected to stop recognizing "CounterSignature" and "CounterSignature0". That said, i would probably be good to have RFC-to-be 9052 and this document handle this the same way.
> >
> > I support warning that over time we expect implementations to phase out
> > support for the legacy structures. I mostly expect that we would have a
> > new document in a year or two that formally Updates 9052 to ease this
> > requirement (but I also wouldn't mind if we decided to put that change into
> > the current -countersign document). I'm not sure if that aligns with your
> > indicated preference to handle things the same way with 9052 and
> > -countersign.
>
> It sounds like it would be better to wait for that follow-on document to soften the backward compatibility requirement. At that point, RFC-to-be 9052 and -countersign will probably become one document.
Okay. (Obviously we can see if anyone else chimes in on this point, too.)
> >>> Section 3
> >>>
> >>> timestamp, a time point at which the signature exists. When done on
> >>> a COSE_Sign, this is the same as applying a second signature to the
> >>> payload and adding a parallel signature as a new COSE_Signature is
> >>> the preferred method.
> >>>
> >>> I don't think I understand what this is trying to say, as what it seems to say
> >>> to me doesn't make sense. In particular, this seems to say that the act of
> >>> applying a countersignature to a COSE_Sign structure is functionally
> >>> equivalent to just appending to the "signatures" array of the COSE_Sign
> >>> object, and indeed that appending to "signatures" is preferred. But that
> >>> seems to provide semantics that are not the (desired) semantics of a true
> >>> countersignature, which would cover the existing (primary) signature in
> >>> addition to the content!
> >>
> >> Wow. This error has been here a very long time. Thanks for noticing!
> >>
> >> ... That is, the countersignature makes a
> >> statement about the existence of a signature and, when used as a
> >> timestamp, a point in time at which the signature exists. When a
> >> timestamp is not used, a countersignature on a COSE_Sign is the same
> >> as applying a second signature to the payload; therefore, adding a
> >> parallel signature as a new COSE_Signature is the preferred method.
> >
> > I had to read this several times to convince myself that it makes sense, so
> > let me write out some description of how I resolved it, to try to
> > cross-check my reasoning.
> > Just as a baseline/refresher (since I've confused myself about it in the
> > past), the primary COSE structures for signatures are COSE_Sign and
> > COSE_Sign1; the COSE_Signature structure is a substructure that holds "the
> > signature and information about the signature". When we construct a
> > countersignature on a COSE_Sign, the procedures have us pull into the
> > to-be-signed bytes both the payload and "all bstr fields after the second"
> > (among other things), but since COSE_Sign has only two bstr fields
> > (protected_headers and payload), that means the "other_fields" element is
> > omitted. In particular, the "signatures" member of COSE_Sign is an array
> > and not a bstr, so the other existing signatures in the COSE_Sign are not
> > included in other_fields and thus not covered by the countersignature --
> > we'd need to apply the countersignature on the COSE_Signature object itself
> > in order to do that. Having made that insight, the focus in the new text
> > about timestamp/no-timestamp does make more sense, and in the no-timestampp
> > case the countersignature's to-be-signed bytes basically match those of a
> > primary signature ("new COSE_Signature [in the COSE_Sign]"), and the
> > recommendation here does make more sense.
> >
> > That said, this seems to be the only place in the document where we mention
> > "timestamp", so I wonder if we want to put some additional discussion
> > somewhere about the mechanics of using a countersignature to add a
> > timestamp (e.g., in external_aad?).
>
> I am not sure how to resolve this since RFC-to-be 9052 does not talk about timestamps at all. I think it go in the protected header.
I think I see two possible routes for this, if we want to do anything.
The first would be in §3, around "A normal example of a countersignature is
the signature that a notary public places on a document as witnessing that
you have signed the document", which we could extend with something like
"This notary usage typically also includes a timestamp for when the
notarization occurs; such a signature timestamp is not defined in core
COSE, but might be included in a (not-yet-defined) protected header
parameter".
The second would be as part of the text in §3 that we're discussing, maybe
something like:
... That is, the countersignature makes a
statement about the existence of a signature and, when a timestamp is
covered by the signature (e.g., in a to-be-defined protected header
parameter), a point in time at which the signature exists. When a
timestamp is not used, a countersignature on a COSE_Sign is the same as
applying a second signature to the payload; therefore, adding a parallel
signature as a new COSE_Signature is the preferred method.
... and as I read this again, I'm questioning whether there is actually a
difference between the timestamp-used and timestamp-not-used cases --
couldn't the timestamp at which the signature exists be encoded in the new
COSE_Signature just as well as the countersignature?
-Ben
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
