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

On 2022-02-21 15:31, Hannes Tschofenig wrote:
> Hi Anders,

Hi Hannes,

> I assume you are focusing on signing the CWT (rather than also encrypting it).

I have (among many things) rather tried to figure out the rationale behind having a multitude of more or less incompatible serializations options for EAT.

Since I couldn't find any valid reason for using JSON, I looked into CBOR only :)

The rationale for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-8.3.1 must be RAM considerations, right?.  If this is the case, PureEdDSA is also a hurdle.  Is EdDSAph in scope?

> The size of a CWT (with relevance to RATS) is fairly small and holding the CWT in RAM is not a problem. The example in https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-08 has 417 bytes.

That was my assumption also.

> I could, however, imagine to write an COSE implementation that does not require the entire CWT be held in RAM since the digital signature just covers the hash of the CWT and you can use a rolling hash.

You mean that only the claims (payload) would be RAM-backed?  That should of course work.

Using the enhanced "COSE" scheme I outlined in the GitHub issue, you would in some (many?, all?) EAT cases need close to zero RAM if you also use a rolling hash.  Caveat: you must beforehand know how many items you are about to produce.

Cheers,
Anders

> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Anders Rundgren
> Sent: Monday, February 21, 2022 7:17 AM
> To: rats@ietf.org; cose@ietf.org
> Subject: [Rats] RAM requirements for COSE/CWT
> 
> Pardon the cross-posting...
> 
> A pretty strange subject line, right? :)
> 
> However, there is a reality in the form of constrained devices that in order to use COSE must either turn to yucky infinite-length encoding (https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-8.3.1) or create the entire payload in RAM, here assuming that the exact size of the payload in bytes is not known in advance.
> 
> X.509 certificates (that were created in a time when virtually all devices were constrained) do not suffer from these problems due to their reliance on deterministic encoding, followed by a separate signature item.   A further advantage of the X.509 approach compared to COSE/CWT, is that the claims are not stuffed in a blob requiring yet another layer of decoding.  However, compared to ASN.1, CBOR is much more "RAM-friendly" since it doesn't impose a byte-length over items enclosed in a map or array.  Concatenation is all you need!
> 
> I believe the time has come to seriously look into alternatives to COSE since it was "inspired" by JOSE.   CBOR <<>> JSON.
> 
> This GitHub issue elaborates a bit more on this topic: https://github.com/ietf-rats-wg/eat/issues/168
> 
> Thanx,
> Anders
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.