Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Michael Richardson <[e-mail]>]

I've read the exchange between Laurence and Carsten and Anders.

If we accept that the only constrained part will be the Attesting Environment
on the Attester, and that all other systems (Verifier, RP) are at least >
class 2 (RFC7228), then we clearly should be optimizing for ease of encoding.

While my experiences with Op-Tee is rather shallow (I compiled it once),
my impression is that it is at least class 2 in size.  A bit of memory
allocation won't be a problem, or pre-allocating a few kilobytes for the CWT
won't be a problem.

I have experience with QCBOR, TinyCBOR and NanoCBR.
My experience is that indefinite length strings are not really needed as long
as one is encoding into a memory buffer.  Noting where the length box is and
filling it in later isn't impossible, but it certainly is harder if one
doesn't have an estimate of the size to know which integer size to use.
Worst case, one can assume that the strings can't exceed the size of the
output buffer!

My claim that an output buffer is needed is that we are going to sign it all,
and while one can construct SHA256 hash calculators that don't need the bytes all
in a row, it's such a pain to do generically, that if one is doing it, one is
creating a bespoke hasher.

I see no strong reason to rule indefinite encodings out: Verifiers and RPs should be
prepared to process them.  I would not encourage their use by encoders.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide