Conversation
tmshort
added
hold: need omc decision
branch: master
|
This PR is in a state where it requires action by @openssl/omc but the last update was 30 days ago |
|
OMC have voted to lift the OMC hold on this PR. |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago |
github-actions
Bot
added
the
severity: fips change
|
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago |
3d6404b to
627a267
Compare
|
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago |
b81ba1e to
8e6bcdb
Compare
|
Had to reconcile with Certificate Compression. Since RPK is an explicit opt-in, certificate compression is opt-out, and RPKs are smaller than compressed certificates, RPKs are preferred over compressed certificates. In addition, RPKs will not be compressed (i.e. you won't find a RPK in a Compressed Certificate message). |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago |
|
ping @openssl/committers ? |
|
The upper layer APis in this PR are heading down the wrong path and need to be reimplemented We all already have a well established mechanism for verifying certificate chains by just their public KEY material. This is takes the form of DANE-EE(3) with a selector of SPKI(1). The Note that the DANE support in OpenSSL does not perform any DNS lookups. The TLSA records configured for the SSL session can come from any source, including computed from explicit key material as in the DANE tests. All the criticism aside, it is nice to see the low-level support implemented for raw public keys, this is a good time to hook it into the DANE layers of the library, improving both the RPK support and DANE. |
|
Thanks @vdukhovni, I'm not familiar with DANE. Given that RPKs are just that, a single key, will using DANE work without a chain? That being said, I'm a bit confused as to why DANE doesn't do DNS lookups, or how could handle keys that don't have any other identifying information. DANE is mentioned as only one possible method of obtaining a public key for verification in RFC7250, but not the only method. It seems odd to me to have to configure DANE in order to use something as simple as raw public keys; the current APIs shouldn't preclude the use of DANE, but it also doesn't require the use of DANE. All references in RFC7250 mention acquiring a public key out-of-band (including DANE out-of-band). It's something I'll have to research. |
mattcaswell
left a comment
mattcaswell
left a comment
There was a problem hiding this comment.
Approved. Ping @vdukhovni to reconfirm your earlier approval
vdukhovni
left a comment
vdukhovni
left a comment
There was a problem hiding this comment.
I reviewed the changes, re-ran the tests, and also tested a Postfix+RPK build.
All good. Reconfirming approval.
mattcaswell
added
approval: done
openssl-machine
added
approval: ready to merge
|
This pull request is ready to merge |
Add support for the RFC7250 certificate-type extensions. Alows the use of only private keys for connection (i.e. certs not needed). Add APIs Add unit tests Add documentation Add s_client/s_server support Reviewed-by: Matt Caswell <[email protected]> Reviewed-by: Viktor Dukhovni <[email protected]> (Merged from #18185)
|
Merged to master. Thank you all for your efforts in getting this in! |
|
Thanks @tmshort for your work on this! |
Yes, very much appreciated, especially for being willing to adapt the design to benefit from and in turn enrich the existing DANE support. |
8 participants
Add support for the RFC7250 extensions, allows the use of only private
keys for connection (i.e. certs not needed).
Fixes #6929
Replacement for #16620 (since github doesn't allow changing the source of a PR)
Add APIs
Add unit tests
Add documentation
Add s_client/s_server support
Checklist