Hi,
Sorry this is a comment coming very late, but I'm afraid I have identified a
very serious issue with counter signatures that I wish to rise here as it seems
to me to be important.
I would be really happy to be totally wrong about it, but that would require a
very deep misunderstanding about them that would in any case require some
clarifications in the text.
I have seen this actually some weeks ago, but until now some of the text about
countersignatures got me so confused I wasn't sure I didn't wrongly interpret
major parts of it.
So here's my reading step by step of the specifications about countersignature,
and why I have an issue with it of a contradiction between what it says is
intended to and what is really achieved, and also for me deep unclarity about
what the payload of a countersignature consists of :
---------
3.1. Common COSE Header Parameters
The counter signature header
parameter can occur as an unprotected attribute in any of the
following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These
structures all have the same beginning elements, so that a
consistent calculation of the counter signature can be computed.
Details on counter signatures are found in Section 5
Nonetheless, they are differences between those formats that at least impact
the payload, and the text doesn't clarify explicitly how they impact
counter-signatures
---------
5. Counter Signatures
A counter signature is normally defined as a second signature that
confirms a primary signature. A normal example of a counter
signature is the signature that a notary public places on a document
as witnessing that you have signed the document. Thus applying a
counter signature to either the COSE_Signature or COSE_Sign1 objects
match this traditional definition.
This will only be true if the payload of the counter signature incorporates the
byte string representing the primary signature value.
If this not the case for COSE counter signature, this text MUST be removed and
clarification otherwise MUST be brought to the standard.
The use of the term counter signature will then be misleading, and should be
considered to be removed.
When done on a COSE_Signature, the normal counter signature semantics
are preserved. That is the counter signature makes a statement about
the existence of a signature and, when used as a timestamp, a time
point at which the signature exists
This will only be true if the payload of the counter signature incorporates the
byte string representing the primary signature value.
If this not the case for COSE counter signature, this text MUST be removed and
clarification otherwise MUST be brought to the standard.
The use of the term counter signature will then be misleading, and should be
considered to be removed.
When done on a COSE_Mac or a
COSE_Mac0, one effectively upgrades the MAC operation to a signature
operation.
This will be true even when the payload of the counter signature only
incorporates the mac 'payload', and not its 'tag'.
When done on a COSE_Encrypt or COSE_Encrypt0, the
existence of the encrypted data is attested to.
This will be true even when only 'ciphertext' is included in the
countersignature payload.
---------
5.1. Full Counter Signatures
The process of creating and validating abbreviated
counter signatures is defined in Section 4.4.
1) abbreviated here seems be a typo
2) The process in Section 4.4 doesn't specify explicitly how to populate the
payload element of the Sig_structure in the case of a counter signature
Clarification about that is absolutely required either here in section 5.1 or
in section 4.4
---------
4.4. Signing and Verification Process
5. The payload to be signed encoded in a bstr type. The payload is
placed here independent of how it is transported.
1) For counter signature of a signature, the simplest interpretation of this
text is that the payload is the 'payload' element of the initial signature.
They are however major issues if interpreted like that.
If I have read its source correctly, the COSE-JAVA implementation does do
counter-signatures of signatures this way.
If this is what's intended, then COSE counter signatures aren't counter
signatures in the classical meaning, they are in fact basically fully
equivalent to cosignatures, given that what they include is only the primary
payload, and doesn't include the primary signature.
So all text suggesting otherwise should be removed from the standard.
New text should be added to make it extremely clear that those signatures can't
function as actual counter-signatures.
I would actually be in favor of removing use of the term counter-signature
given how misleading it would be then.
If the intent is for counter signature in this standard to be real counter
signatures, then an explicit clarification is required about how 'payload' is
populated.
The simplest solution is probably to say that it includes all of the primary
signature structure, except that all of the 'unprotected' headers shall be
removed first (there would be recursion problems otherwise)
This specifically solves the issue of specifying which of the initial signature
is countersigned in case they are multiple signers.
Solution to include less of the initial structure in the counter signature seem
to be more complex, and would need anyway to include all of the initial
signers, except if designing a way to specify only one of them
(maybe when the counter signature is inserted inside the 'unprotected' element
of his specific signature ?).
2) For counter signature of a mac, the simplest interpretation of this text is
that the payload is the 'payload' element of the initial signature and 'tag'
isn't included in the countersignature.
There's not a major issue if interpreted like that, as I didn't see a claim
that this would contradict.
3) For encrypted content, the simplest interpretation of this text is that the
payload is the 'ciphertext' element .
There's not a major issue if interpreted like that, nonetheless it would be
made clearer by specifying it explicitly
---------
5.2. Abbreviated Counter Signatures
Instead, the parameters for computing or verifying the
abbreviated counter signature are inferred from the same context used
to describe the encryption, signature, or MAC processing
1) This appears to mean that if a signature with a single signer is
counter-signed this way, the content + the protected headers + the signer are
the same as the initial signature ?
If so, it doesn't seem to have much value, since it resigns exactly the
same thing (except the signer protected header if applicable), so it should be
made even more explicit
If they are multiple signers of the initial signature, is it intended that the
signer must be the first of the list ?
For mac and encryption, it's unclear how the signer public key will be
identified, as we have only the information for the mac/encryption key.
If what is actually intended that the identification of the counter-signer is
through an out-of-band mechanism and doesn't need to have a relation with the
counter signed element signature, encryption or mac, this should be specified.
2) To function as an actual counter-signature for signatures, the same issue
with the payload is present as for full counter signatures
3) There is no sample of an abbreviated counter signature
---------------
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
