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

[Anders Rundgren <[e-mail]>]

On 2022-02-24 2:46, Laurence Lundblade wrote:

> I believe the targets motivating full encoding variance for EAT are pure hardware implementations.

Although I may have misinterpreted Carsten, I think he rather objected to not have this as a default for *all* EAT objects since (in his mind) decoders are *obliged* to deal with this:
https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-8.3.1

> Think of a TPM-like chip that outputs EAT. Or a HW IP core that ARM sells for your SoC.

AFAIK, TPMs currently use DER-encoding which is way more complex than preferred serialization a la CBOR.  My guess is that these systems use precomputed data structures and only fill the blanks. In the early days of Android I had to create an XML Dsig.  I started with porting a pretty complex canoncalization library but later replaced it with a handful of "printf"-like lines.

You may not be aware of this, but there are hordes of people who do not like having their precious data wrapped in base64url (JWT) or bstr (CWT) unless it is proven necessary:
https://github.com/ietf-rats-wg/eat/issues/168#issuecomment-1045958031
This is another side of the coin which stretches far outside the scope of EAT.

Anyway, since you will only get one shot at this topic, I thought it was worth a discussion even if we don't come to the same conclusion :)

I leave it there.  In case you have a minute or two you may try out an on-line CBOR encoder+decoder+signature system that is not burdened by legacy:
https://test.webpki.org/csf-lab/home

Cheers,
Anders

> 
> 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 <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats