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

Prohibit the inclusion of dataEncipherment and keyAgreement KU bits #384

Open
CBonnell opened this issue Aug 25, 2022 · 2 comments
Open
Labels
profiles-future Item for a future profiles ballot validation-sc

Comments

@CBonnell
Copy link
Member

CBonnell commented Aug 25, 2022

It was decided at the Warsaw F2F to push back the prohibition on the inclusion of dataEncipherment and keyAgreement KU bits to after Profiles v1 and instead mark them as NOT RECOMMENDED with a note they will be prohibited in the future.

This issue tracks implementing this prohibition.

@CBonnell CBonnell changed the title Prohibit the inclusion of dataEncipherment and keyExchange KU bits Prohibit the inclusion of dataEncipherment and keyAgreement KU bits Aug 25, 2022
@CBonnell CBonnell moved this to Backlog in Validation Aug 25, 2022
@CBonnell CBonnell added validation-sc profiles-future Item for a future profiles ballot labels Aug 29, 2022
@wthayer
Copy link
Contributor

wthayer commented Nov 5, 2023

Discussed at 11/2/23 Validation subcommittee meeting. Agreed that this should be split into two tasks - one for RSA and one for EC.

@vanbroup
Copy link
Member

vanbroup commented Jan 8, 2024

The pending prohibition of dataEncipherment came up in zlint:
zmap/zlint#708 (comment)

The lint was created by the PKI Consortium, and it took some time to come to a mutual understanding on the language of the RFC, this is why we also clearly documented the lint and searched for any issues in the ct-logs before releasing the lint.

This is the section of the lint that talks about server-authentication:

      // KU combinations with Server Authentication EKU:
      //  RFC 5280 4.2.1.12 on KU consistency with Server Authentication EKU:
      //    -- TLS WWW server authentication
      //    -- Key usage bits that may be consistent: digitalSignature,
      //    -- keyEncipherment or keyAgreement

      // (digitalSignature OR (keyEncipherment XOR keyAgreement))
      x509.ExtKeyUsageServerAuth: {
            x509.KeyUsageDigitalSignature:                                true,
            x509.KeyUsageKeyEncipherment:                                 true,
            x509.KeyUsageKeyAgreement:                                    true,
            x509.KeyUsageDigitalSignature | x509.KeyUsageKeyEncipherment: true,
            x509.KeyUsageDigitalSignature | x509.KeyUsageKeyAgreement:    true,
      },

It's clear that dataEncipherment is not allowed for server auth, but it might be fine if another EKU is present that does allow dataEncipherment. That stated, it's not listed as allowed for any of the EKUs defined in RFC 5280, this even states:

The dataEncipherment bit is asserted when the subject public key
is used for directly enciphering raw user data without the use of
an intermediate symmetric cipher. Note that the use of this bit
is extremely uncommon;
almost all applications use key transport
or key agreement to establish a symmetric key.

The BRs seem to deviate from RFC 5280 here, should we re-evaluate this topic and move at least dataEncipherment from Pending Prohibition to prohibited?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
profiles-future Item for a future profiles ballot validation-sc
Projects
Status: Backlog
Development

No branches or pull requests

3 participants