-
Notifications
You must be signed in to change notification settings - Fork 927
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
transports: Deterministic certificate generation #3049
Comments
I've spent today looking into ways of doing it. One way is // Convert `identity::KeyPair` into `rcgen::KeyPair`.
let der = id_keys.serialize_der();
let key_pair = rcgen::KeyPair::from_der(der).map_err(ConfigError::CertificateGenError)?;
params.key_pair = Some(key_pair); convert @thomaseizinger pointed out that it might be simpler to use HKDF that will act as the seed for randomness (at what point? during certificate creation https://docs.rs/rcgen/0.10.0/rcgen/struct.CertificateParams.html#structfield.serial_number?). |
I think we need to patch There is also randomness in the ECDSA signature on the certificate itself so if you want truly deterministic certificates, that needs to be fixed too. Just the same For the HKDF, it is probably better to generate the certificate seed and the keypair from different derivations from a common secret and not the certificate from the keypair. |
I would guess @MarcoPolo has opinions here given his related work on libp2p/go-libp2p#1833. |
If patching |
As mentioned in melekes#12, this is blocked on briansmith/ring@fe9e4d0 getting released and |
I think this would also be easier to resolve with #3659 because str0m depends on openssl and to parse the cerificate, meaning we don't necessarily need to use |
This now also affects WebTransport: #4874 |
While its possible to get around this by generating the cert outside of the behaviour, i think until ring does ever support RFC6979, we should probably do a workaround, though might be considered hacky, but would get the job done to make the cert deterministic out of the box for webrtc (and webtransport when the server side is implemented in libp2p) vs outside workarounds. |
Presently (#2622), the certificate is supposed to be generated and stored somewhere along the node's key. This could be improved. As it was pointed out in the spec, we should be able to derive a TLS certificate from node's key. This will improve dev experience.
The text was updated successfully, but these errors were encountered: