You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no need for this additional signature of the voucher, because there
is no need for the pledge to to perform verification beyond anything but the
vouchers content according to RFC8995 Section 5.6.1 and an equivalent of Section
5.6.2.
Aka: the Pledge need to verify the MASA signature on the voucher and that
its addressed by the voucher (serial number matching), then the nonce, and
then it can finally accept the pinned domain certificate from the voucher
and use that to perform additional verification. This is where we might need
new text/difference over rfc8995:
Effectively i think that the pledge simply has to check the register-agent
LDevID signature on the trigger messages against the pinned domain
certificate, and if this can't authenticate the Trigger messages, then those trigger
messages will be ignored - as well as the replies that the registrar-agent
may issue for the PER.
Having said this: there may be different benefits wrt. traceability of why one
may need to add a signature of the registrar, but those should then be explained.
I for once would rather like to try to find the simplest form that we know
would be secure instead of just adding signatures without good understanding of
need.
The text was updated successfully, but these errors were encountered:
The second signature of the voucher has different purposes.
It provides assurance to the pledge that the registrar (the pledge got the server certificate of the registrar in the PVR) does indeed possess the corresponding private key (as proof-of-possession). In BRSKI proof-of-possession is done in the TLS handshake, which BRSKI-PRM does not use.
The verification of the signature proves that the registrar possesses this private key and can be validated together with the domain certificate received in the voucher. This ends the PROVISIONAL accept of server cert .
Comment from Toerless to section 6.2.5:
The text was updated successfully, but these errors were encountered: