Prohibit the inclusion of dataEncipherment and keyAgreement KU bits

[CBonnell]

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.

[wthayer]

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]

The pending prohibition of dataEncipherment came up in zlint: https://github.com/zmap/zlint/pull/708#issuecomment-1875606606

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?