This was an error I introduced when streamlining the previous iteration of the protocol design to always have public verifiability (i.e., it was not included in the Danezis suggestion).
The CEK included in the report must be the one with indexj1-1, not index j1, because the recipient of the report cannot verify that the provided CEK was generated bound to rvk. Otherwise a malicious user can submit a report containing one CEK (the first one) which they did not generate. This mistake was pointed out by Joseph Jaeger and Stefano Tessaro.
This was an error I introduced when streamlining the previous iteration of the protocol design to always have public verifiability (i.e., it was not included in the Danezis suggestion).
The CEK included in the report must be the one with index
j1-1
, not indexj1
, because the recipient of the report cannot verify that the provided CEK was generated bound torvk
. Otherwise a malicious user can submit a report containing one CEK (the first one) which they did not generate. This mistake was pointed out by Joseph Jaeger and Stefano Tessaro.