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

I believe the targets motivating full encoding variance for EAT are pure hardware implementations. Think of a TPM-like chip that outputs EAT. Or a HW IP core that ARM sells for your SoC.

I’m pretty sure this is quite possible without any SW (except the driver SW for the EAT attestation core, network stack and such that doesn’t need to be secure).

Experience with SW implementation like QCBOR is not particularly relevant.

LL

> On Feb 23, 2022, at 2:42 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats