On Sun, Dec 29, 2024 at 07:39:20PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > Perhaps the below will help? > > > https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0 <https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0> > > https://www.youtube.com/watch?v=OuH4vwmzP_o <https://www.youtube.com/watch?v=OuH4vwmzP_o> > > Oh, it absolutely does – thank you! You're welcome, it is reasonable to guess you read the slides, and did not watch the recording. > $ openssl verify -show_chain -CAfile dsa-ca.pem kem-cert.pem > kem-cert.pem: OK > Chain: > depth=0: CN=PQ_KEM_Entity (untrusted) > depth=1: CN=Experimental_PQ_CA > $ > $ > $ openssl verify -show_chain -trusted dsa-ca.pem kem-cert.pem > kem-cert.pem: OK > Chain: > depth=0: CN=PQ_KEM_Entity (untrusted) > depth=1: CN=Experimental_PQ_CA > $ > > Perhaps you could clue me in regarding “(untrusted)” in the above? The "untrusted" (not a priori trusted) certificates were not from the trust store, I think I mentioned this during the presentation. > Also, am I correct to assume that if I choose to prepare extension > templates, those files would look like: For CA template > (ca-template.txt): > basicConstraints = critical, CA:TRUE, pathlen:1 > keyUsage = critical, digitalSignature, nonRepudiation, keyCertSign The output of the <(...) commands used as `-extfile` values in bash-compatible shells can of course be saved in actual files. The `openssl x509` just reads (without seeking) data from a file, which can be a command pipe. > For KEM cert template (kem-template.txt): > basicConstraints = critical, CA:FALSE > keyUsage = critical, keyEncipherment > > and I’d be able to refer to them in the “openssl x509 …..” command > above as “-extfile kem-template.txt”? I couldn't be otherwise, if you're comfortable with <(...) support in your shell. > If the format of the above files should be more elaborate – I’d > appreciate being “clued in”! It is an extension file, same syntax as "openssl.cnf", including support for subsections: [some_sect] some_thing = some_value other_think = other_value if you need it. The only difference is that this the "extensions" section of that file, so no "newoid" or other things that don't make sense in the extensions section. > > Then, assuming it still makes sense for the payload to be an X.509 > > certificate, and not something much simpler (like a delegated > > credential), you should be all set. > > Unless I’m mistaken, delegated credentials are supposed to have very > short lifetime, and be “renewed” (re-“retrieved”) quite often. They are a TLS construct. In non-TLS contexts, you could invent and use something similarly streamlined that conveys a key, but is not a full X.509 certificate. Particularly if there's a need for non-CAs (EE key holders) to be able to sign these, which they cannot with X.509, as they are not CAs. So delegated credetials are carried in a separate TLS extension, they are not part of the cert chain. But one can, for example, imagine a situation where a delegated credential signed by the EE public key, is used in combination with RFC7250 raw public keys... But for this to make sense, one would still need something like KEMTLS to make it possible for the KEM key to authenticate the handshake. > My use case suggests (reasonably) long-term certificates, whose main > difference from the traditional PKI for TLS or IPsec is that they’re > used in implicit authentication, rather than for generating dynamic > signatures during the handshake. The main difficulty is that, as X.509 certs, verified in the usual way, these would need to be issued by a trusted CA, whereas CAs willing to issue KEM certs are pretty thin on the ground. With designs like delegated credentials the EE key holder can mint their own. This may not be a concern in your use-case, your mileage may vary... > Perhaps, I need to understand “delegated credentials” better. Though > there’d be a question of whether my infrastructure is ready and > willing to embrace that concept, and the workflows it would require… They're lightweight assertions that the key in the credential is authorised to act on behalf of the signing EE cert key holder. They can be issued by the EE key holder without involving any 3rd-party CA. They require protocol support, the TLS extension needs to be implemented on both ends. -- Viktor. -- You received this message because you are subscribed to the Google Groups "openssl-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx. To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/Z3GxIjEQzi2a3kzK%40chardros.imrryr.org.
