On 02/04/2015 10:05 PM, Richard Barnes wrote:
The one thing we should be abundantly clear on is the relationship between "COSE" and "JOSE". In particular, that what we're talking about is *not* simply a re-encoding -- a JOSE signed object (JWS) and a COSE signed object will have different signature values.So the main value will be in re-using identifiers (e.g., header field names) and the overall structure (header, protected, etc.). Agreed?
Yes, but ... (Sorry for the long mail ahead, TL;DR: Do this and more!) I've done a few quick calculations on that topic.A simple JWS (alg='HS256', kid=<16 chars>, not including any of the payload, just the signature and the header) would have a size of 100 bytes.
Simple translation of that to CBOR (as suggested in Carstens presentation at IETF90) shrinks this down to 67 bytes.
In the constrained devices use cases, the data we would want to protect with JW* would typically be sensor readings and actuator commands. These would have a size of just a few bytes (say a 4 byte float for example). Adding 67 bytes overhead to that still seems pretty steep.
Therefore I would suggest to also consider what Carsten mentioned on slide 35 (last bullet) of this:
http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdfIt basically boils down to define abbreviations for common member names and pre-defined values (such as 'alg', 'enc', 'kid', 'HS256').
Furthermore I suggest to define new algorithm identifiers for e.g. truncated MACs, and for AES_128_CCM_8 (AFAIK CCM mode is more efficient to implement in constrained devices than GCM).
Hope this helps, Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
