Richard, After talking with Bob at the last F2F meeting, I think I got my usage case fleshed out. I don't have access to your draft at the moment so I can't harmonize with how things look, but I am sure you will be able to
X.X Constrained Devices There is a class of devices that are starting to come online that need to be able to do secure communications, but are very constrained both in terms of power and in terms of memory. One additional constraint is that these devices have minimal cryptographic functionality. Thus these devices have exponentiation and AES block encryption/decryption, but they do not have any hash functions built nor do they have enough memory for a software implementation. As such they can do EC-DH key agreement, but use an AES based KDF function for generating keys for encryption/decryption or MAC operations. One side effect of not having any hash functionality is that they have no ability at present to use TLS for any message protection. These devices are power constrained; this means that every byte that is transmitted over the net to another device is a drain. For this reason the smaller the message the better, the environment that they are working in however is better than that of the HTTP header in that they can transmit binary data without any problems. Thus for these devices there is no requirement that the data be converted to base64 prior to transmission. This is actually an undesirable step as it increases the size of the message to be transmitted. A better method of encoding the headers would be to use a length prefixed format for each of the pieces as this would produce a smaller transmission block. These devices would use UDP or the output of the CORE working group for transmission of data thus leading to a hard limit on the size of messages in the case of UDP. For these devices the messages are going to be extremely constrained, as such this means that allowing for a fixed order of the headers and any content fields is highly desirable. Having a fixed order simplifies the parsing as does the ability to specify a canonicalization of the encoding to minimize the number and location of characters that are not needed for parsing the fields of a JSON structure. Any devices operating in this environment would need to define some new algorithms as they will be operating in a static-static EC-DH mode (combined with constrained environments, this can provide some assurance on who originates the message) and a new AES based KDF function to move from the agreed secret to the content encryption key or MAC key used for protection on the message. This would also require defining a new MAC algorithm which allows for key derivation but no content encryption. It is possible that these environments would be fully satisfied with AES-GCC encryption mode however. These devices would use internal methods for deciding which keys can be trusted and what they are named. This means that all keys can be easily identified for all parties. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
