Jean-Marc, I think that you have a deep misunderstanding about this and we need to find what the text is that is both confusing and how to get clarifications.
> -----Original Message----- > From: DESPERRIER Jean-Marc <[email protected]> > Sent: Thursday, June 18, 2020 10:22 AM > To: Jim Schaad <[email protected]>; 'Benjamin Kaduk' <[email protected]> > Cc: [email protected]; [email protected]; 'Matthew > Miller' <[email protected]>; 'The IESG' <[email protected]>; > [email protected] > Subject: RE: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > struct-10: (with DISCUSS and COMMENT) > > 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 So the first three elements are: * Protected headers * Unprotected headers * Payload of the object In section 5 there is text which says "that the countersignature operation needs to be treated as a separate operation from the initial operation". The purpose of this text was to state that all of the cryptographic operations on the target of the countersignature need to be completed prior to starting the countersignature operation. This means that looking at that array of items above there is a binary string, a map, and a binary string. The countersignature operation is totally agnostic to how that last byte string is created. It has to be or else a third party would not be able to apply a countersignature. > > --------- > 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. [JLS] As noted above that is exactly what the payload is > > 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. [JLS] As noted above, this is true for applying to a COSE_Signature. > > 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'. [JLS] As noted above, only the first three elements of the COSE_Mac and COSE_Mac0 structures are used when computing the countersignature. This means that the tag, which is the fourth element is not included. > > 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. [JLS] As noted above, the ciphertext is what is used. > > --------- > 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 [JLS] My dictionary tells me that this is correctly spelt. > > 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 [JLS] I will add clarification in the text that the COSE_Signature structure is what is referred to when it says that the details of the fields of a countersignature are found in section 4.1. > > --------- > 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 > ?). [JLS] Yes I can see how this is confusing. I will add a paragraph on how to determine what the payload is for a countersignature operation. > > 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. [JLS] I will start by saying that I have never liked the abbreviated countersignature, but it is useful in some circumstances. The easiest document to look at where both an encryption key and signature key are associated draft-ietf-core-oscore-groupcomm. In this case while each person in the group has a unique key, that key is also known by everybody else in the group so that key cannot be used for the purpose of determining who encrypted and sent the message. This information is added by the addition of an abbreviated countersignature to the end of the encrypted message. This, combined with a large amount of externally supplied authenticated data to both the encryption and signature process, allows for proper identification of the entity which sent the message. There is only one set of key identification material however and that is to identify the encryption key which was used. The same identifiers used for the encryption key can then be used to figure out which signature key (s) would make sense to check. [JLS] In the case that you suggested above, that of an abbreviated countersignature on a signature, when you went to retrieve the key information on the signing key, I would expect that you would get back an array of two signing keys. The first for the signature and the second for the countersignature. I would really wonder at a case where this is being done however. Why are you sufficiently worried about size that you are using an abbreviated countersignature in this situation, but you are not just going to replace the original signature with one of your own. > > 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 [JLS] I have these and can put one or two into the appendixes. Jim > --------------- _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
