On Tue, May 20, 2025 at 9:14 AM Eliot Lear via NANOG <[email protected]> wrote: > On 19.05.2025 03:27, Tom Beecher via NANOG wrote: > In other words, EKU is a horrible mishmash of authentication and > authorization because the signer is prohibiting the principal from using
EKU is also an optional extension. Nothing in the standard says you have to use it. Nothing in the standard suggests that you should or ought to use it. I would strongly suggest that you don't need to set an EKU, and the CAs should not add an EKU unless you the person who are applying for the certificate requested that they do so. The CA could also sign a certificate for you which authorizes you to sign your own certificates for the same subject list, and provide you the capability to compartmentalize your keys however is appropriate for your deployment. > the certificate for certain purposes. There are $REASONs for this, but > I'd really like to hear them. I believe that's because a X.500 directory also has what I would consider to be administrative controls. One of the things the CA might want to do is differentiate certain services. For example: Your identity is proven, but the CA wishes to only authorize you to digitally sign to verify the authorship of a document or email, and not grant the ability to sign a piece of software or code without an extra $1000 fee paid to the CA for "Code signing access". One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. For example: You have a secret key you want to install on a web server, and a secret key your server to sign authentication tickets with. Both certificates are for the same FQDN, but the web server certificate is at higher risk of the secret key being comrpomised in your specific deployment, while your secret key for the Token signing certificate is stored on a #11 smartcard or hardware security device (HSD), Etc. That means it's a security issue if a relying party would accept a token signed by the web server's secret key. In order to take the appropriate responsibility levels for safeguarding your public key per application - You need a mechanism of adding qualifications to the certificates issued to you which will be visible to the relying parties of the certificate and enforce the restrictions the Subject of the certificate has chosen for their secret key management purposes. > Eliot -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/A2P3KX2HFVXX2IRWZUO7FMGGDS4HATEV/
