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 <[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
