Skip to content

crypto/tls: generate_cert.go sets KeyEncipherment KU for non-RSA keys [freeze exception] #36499

Description

@cpu

What version of Go are you using (go version)?

go version go1.13.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

$ go run ./src/crypto/tls/generate_cert.go -host threeletter.agency -ecdsa-curve=P256

$ openssl x509 -in cert.pem -noout -text | grep -A1 "X509v3 Key Usage:"

What did you expect to see?

            X509v3 Key Usage: critical
                Digital Signature

What did you see instead?

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment

Summary:

The crypto/tls/generate_cert.go utility should only set the template x509.Certificate's KeyUsage field to a value with the x509.KeyUsageKeyEncipherment bits set when the certificate subject public key is an RSA public key, not an ECDSA or ED25519 public key.

Presently it sets the KeyUsage to KeyUsageKeyEncipherment and KeyUsageDigitalSignature no matter what type of public key is used:

KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,

RFC 5480 describes the usage of ECDSA elliptic curve subject keys with X509. Unfortunately while Section 3 "Key Usages Bits" indicates which key usage bits MAY be used with a certificate that indicates id-ecPublicKey in the SubjectPublicKeyInfo field it doesn't provide guidance on which usages should not be included (e.g. the keyEncipherment bit, which is particular to RSA key exchange). The same problem is present in RFC 8410 Section 5 describing Key Usage Bits for ED25519 elliptic curve subject keys.

There's an update to RFC 5480 in last call stage within the IETF LAMPS WG, draft-ietf-lamps-5480-ku-clarifications-00. This update is meant to clarify the allowed Key Usages extension values for certificates with ECDSA subject public keys by adding:

If the keyUsage extension is present in a certificate that indicates id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in SubjectPublicKeyInfo, then following values MUST NOT be present:

keyEncipherment; and
dataEncipherment.

I don't believe there is an update for RFC 8410 in the works but I suspect it will be clarified similarly in the future (I will follow up with the LAMPS WG).

The current behaviour of generate_cert.go won't comply with the updated RFC 5480 requirement.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions