The security handshake step is OPTIONAL in case PSKs are used, while it is
-REQUIRED for RPKs and certificates. When using certificates, the process
-outlined in {{I-D.ietf-6tisch-dtsecurity-secure-join}} would be followed, and
-once complete, the process would continue here with a locally relevant
-security credential, or an established shared secret.
+REQUIRED for RPKs and certificates.
+When using certificates, the process continues as described in {{I-D.selander-ace-cose-ecdhe}},
+but MAY result in no network key being returned. In that case, the pledge enters a
+provisional situation where it provides access to an enrollment mechanism described in
+{{I-D.ietf-6tisch-dtsecurity-secure-join}}.
+If using a locally relevant certificate, the pledge will be able to validate the
+certificate of the JRC via a local trust anchor. In that case, the JRC will
+return networks keys as in the PSK case. This would typically be the case for
+a device which has slept so long that it no longer has valid network keys and must go through
+a partial join process again.
In case the handshake step is omitted, the shared secret used for protection
of the join request and join response in the next step is the PSK.
The Security Handshake step is required, when using asymmetric keys.
Before conducting the Diffie-Hellman key exchange using EDHOC {{I-D.selander-ace-cose-ecdhe}}
the pledge and JRC need to receive and validate each other's public key certificate.
+As detailed above, this can only be done for locally relevant (LDevID) certificates.
+IDevID certificates require entering a provisional state as described in
+{{I-D.ietf-6tisch-dtsecurity-secure-join}}.
When RPKs are pre-configured at pledge and JRC, they can directly proceed to the handshake.
committed
e283fd2