On the side, It appears that the key representations are typically of length 8n
+1. Considering that IPv6 ND aligns its options at 8n bytes, it would make
sense to start a byte ahead like this, don't you think?
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved1| Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | EARO Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Public Key (variable length) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Padding .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Crypto-ID Parameters Option
From: Pascal Thubert (pthubert)
Sent: vendredi 24 avril 2020 15:54
To: 'Benjamin Kaduk' <[email protected]>; Rene Struik <[email protected]>;
Mohit Sethi <[email protected]>
Cc: [email protected]; Shwetha Bhandari (shwethab) <[email protected]>; Jim
Schaad <[email protected]>; Erik Kline <[email protected]>; [email protected]
Subject: AP-ND 22
Hello Benjamin (and 6lo)
We are soliciting your help on AP ND for hopefully the last time, about the
last step, that was supposed to be the IANA section that was missing for JOSE
and Crypto Type 2.
Rene worked quite a bit with Jim and the conclusion that I made from that is
that the formats that we already discussed in appendix B (SEC1) were better
suited than JOSE (or COSE) and avoided both the registry issue and gaps in the
existing specifications.
We had a conversation yesterday with our AD (Erik) and Shepherd (Shwetha) and
we agreed to give a try at using those formats for -22. The conclusion that it
looked OK but we need a validation that the new key and signature formats do
not alter the security of the spec.
So there we go; 20 being the version that made it through IESG, and 21 the
increments that you already reviewed and provides encoding agility, please find
the proposed 22 attached and the diff between the proposed 22 and either 20 or
21.
The main diffs from 21 are
- the removal of JWK,
- a discussion on brown field that basically indicates that a back level 6LR
constitutes a breach in the perimeter, meaning that all 6LRs need to be
upgraded.
- the J flag from 21 is gone, since we dropped JWK and dismissed the idea of
operating AP ND in a brown field.
Can you please have a look and validate that we did OK?
Many, many thanks for all your help throughout!
Pascal, Rene and Mohit
[cid:[email protected]]
Pascal Thubert
PRINCIPAL ENGINEER.ENGINEERING
[email protected]<mailto:[email protected]>
Tel: +33 49 723 2634
cisco.com
Cisco Systems, Inc.
45 All Des Ormes Regus Centre
BP1200
06250 MOUGINS CEDEX
France
[cid:[email protected]]
Think before you print.
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
Please click
here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html>
for Company Registration Information.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
