Hi, Sorry first that I didn't react quicker, at the moment I have other priorities, so I have time to check the latest COSE ML messages only from time to time.
-----Message d'origine----- De : Jim Schaad <[email protected]> > 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. I hope this time we can make decisive progress on this. Let me just forewarn you that I'm now more convinced there's a real issue to solve. But maybe, just by saying that when applied to signature this format doesn't have many of the properties usually associated to a countersignature. > --------- >> 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 [JLS] 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. [JMD] Well, the first two are identical, but the third is very different (even if you disagree on that, maybe it'd be useful to specify "'the same 3 beginning element"). - for encryption, the third ('ciphertext') is the output of the encryption operation. The cleartext is processed, and the result is the content of the element 'ciphertext'. So I agree it works as you describe. - for signature and mac, the third ('payload') is the *input* of the signature/mac operation. When this input is processed, the output is the content of 'tag' for mac and 'signature' for signature. But those are placed inside the fourth and last element of the structure The third is left unmodified by the calculation of the signature. (more precisely, they will be directly the fourth element for mac and Sign1, but for COSE_Sign instead it will be one of the 'signature' element inside the list of COSE_Signature that constitutes the fourth element). So *if* only this 3 elements are used to calculate a COSE counter-signature, then it doesn't have any impact if the cryptographic operations of the initial signature are not done when calculating the counter-signature. Because their output isn't used to calculate it, only their input. And that's exactly why for me, this format then isn't a real counter signature. > --------- > 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 [JMD] Maybe my added clarification above now makes it clear where exactly we diverge in the comprehension of this. > 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. [JMD] Same as above, hoping my text 2 comments above clarifies the divergence. > 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. [JMD] So as I wrote, your text is correct as it just says "upgrades to a signature operation". But when applied on counter signature, the fourth element *must* somehow be included to create a real countersignature. > 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. [JMD] It would be good to have somewhere in the text explicitly the clarification that it's the first 3 element that are used, the third being 'payload' for signature and mac, and 'ciphertext' for encryption. > --------- > 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. [JMD] I meant editorial mistake. The paragraph is "Full Counter Signatures", so the whole word needs to be removed ("process of creating and validating counter signatures"). > 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. [JMD] OK. If indeed only the first three elements are used, then the clarifications also need to go through the whole document to remove the text implying the counter-signature has properties that require being able to protect against modifications of the initial signature that's inside the fourth element. > 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. [JMD] I had a quick look, from 4.1 in draft-ietf-core-oscore-groupcomm, it appears that the determination of the countersignature key is an out-of-band mechanism. So I would add the precision that an out-of-band mechanism or a standardized procedure is required to determine the signature key of an abbreviated countersignature. [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. [JMD] Maybe a note that abbreviated countersignature on a signature are technically allowed, but probably don't have a useful use case in practice would be nice. Like this : "Note : Abbreviated countersignature on a signature are technically possible, but are unlikely to serve a useful practical purpose." > 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. Br, Jean-Marc _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
