There is a > lurking in section 1.2 I found section 3.0 very dense reading. I think that there are several use cases listed, and I'd like them split up in numbered sections that I can refer to.
In the fourth paragrah:
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 feel like s/COSE_Signature/COSE_Countersignature/ here?
section 3.1:
This also means that the countersignature can itself be
countersigned. This is a feature required by protocols such as long-
term archiving services.
I'd like to see this use case expanded somewhere, perhaps with a short example.
RFC4998 is from 2007 and is full of ASN.1 goo. But section 4 (of 4998)has a
nice way to represent the trees with concentric boxes. It wasn't obvious to me
how to translate things. I'm not asking you to do redo 4998 though.
[okay, in context, of 3.1, I now understand why signature algorithm with
message recovery makes no sense]
When you write:
* Using the same key for two different algorithms can leak
information about the key. It is therefore recommended that keys
be restricted to a single algorithm.
I think that where you say "algorithm" you actually mean protocol.
That is, I shouldn't use the same ECDSA secp256k1 key with both OpenPGP and
COSE. I think that "ECDSA" is the algorithm, so the statement would
otherwise be a tautology. But, maybe you are saying that I shouldn't
use the same point with a 256-bit ECDSA and a 384-bit ECDSA?
* Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm exposes the direct key to the second
recipient.
I have no idea what this means. I guess it applies to ECDH more than ECDSA.
I found that the security considerations are not particularly specific to
counter signatures.
A question that I had when reading, is what is the key value to be
used when putting a counter-signature into the unprotected bucket.
I see in the examples that you use 7, which is the same as for RFC8152.
I think that this might warrant more emphasis back in section 2, and
also at the end of section 3.2.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
