Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concept of second signature on voucher #90

Closed
stfries opened this issue Mar 23, 2023 · 2 comments · Fixed by #127
Closed

Concept of second signature on voucher #90

stfries opened this issue Mar 23, 2023 · 2 comments · Fixed by #127
Assignees

Comments

@stfries
Copy link
Collaborator

stfries commented Mar 23, 2023

Comment from Toerless to section 6.2.5:

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.

@stfries
Copy link
Collaborator Author

stfries commented Mar 23, 2023

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 .
  • The additional signature can be used as authorization to install the trust anchor.
    see also Issue Registrar signature on MASA voucher #15

@mcr mcr self-assigned this May 9, 2023
@stfries
Copy link
Collaborator Author

stfries commented May 9, 2023

clarify with response from mcr and incorporate additional information for reasoning.

@siethower siethower removed their assignment Jul 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants