Michael Richardson wrote:
> Mališa Vučinić wrote:
>> Thanks Tero for this feedback! Could you check if this commit takes
>> care of it:
>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/
>>
Tero Kivinen wrote:
> Or we could rename key_usage to key_usage_and_algorithm and split it so
> that (key_usage_and_algorithm & 0x1f) is the actual key_usage, and
> (key_usage_and_algorithm >> 5) is the algorithm id, which would still
> encode
Mališa Vučinić wrote:
> Thanks Tero for this feedback! Could you check if this commit takes
> care of it:
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/
> dee6cf8074f2
> The algorithm identifier is added, it is optional
Tero Kivinen wrote:
> Note, that there is work ongoing in the IEEE to add algorithm agility
> to the IEEE 802.15.4, i.e., make it possible to use other algorithms
> than AES-CCM with 128-bit keys. To make it so that this structure would
> also allow that it would
Mališa Vučinić writes:
> Thanks Tero for this feedback! Could you check if this commit takes care of
> it:
>
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2
>
> The algorithm identifier is added, it is optional and if it is not present the
>
Thanks Tero for this feedback! Could you check if this commit takes care of
it:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2
The algorithm identifier is added, it is optional and if it is not present
the IEEE802154-AES-CCM-128 algorithm is assumed. Apart
On Tue, May 15, 2018 at 8:54 PM Michael Richardson
wrote:
>
>
> > I generalized the rekeying text so that it falls under the
> processing rules
> > of the CBOR Link-Layer Key parameter. The first join of a pledge just
> > becomes a special case but there is a